**Health Informatics**

Alfred Winter · Elske Ammenwerth Reinhold Haux · Michael Marschollek Bianca Steiner · Franziska Jahn

# Health Information Systems

Technological and Management Perspectives

*Third Edition*

**Health Informatics**

This series is directed to health care professionals leading the transformation of health care by using information and knowledge. For over 20 years, Health Informatics has offered a broad range of titles: some address specifc professions such as nursing, medicine, and health administration; others cover special areas of practice such as trauma and radiology; still other books in the series focus on interdisciplinary issues, such as the computer based patient record, electronic health records, and networked health care systems. Editors and authors, eminent experts in their felds, offer their accounts of innovations in health informatics. Increasingly, these accounts go beyond hardware and software to address the role of information in infuencing the transformation of health care delivery systems around the world. The series also increasingly focuses on the users of the information and systems: the organizational, behavioral, and societal changes that accompany the diffusion of information technology in health services environments.

Developments in health care delivery are constant; in recent years, bioinformatics has emerged as a new feld in health informatics to support emerging and ongoing developments in molecular biology. At the same time, further evolution of the feld of health informatics is refected in the introduction of concepts at the macro or health systems delivery level with major national initiatives related to electronic health records (EHR), data standards, and public health informatics.

These changes will continue to shape health services in the twenty-frst century. By making full and creative use of the technology to tame data and to transform information, Health Informatics will foster the development and use of new knowledge in health care.

Alfred Winter • Elske Ammenwerth Reinhold Haux • Michael Marschollek Bianca Steiner • Franziska Jahn

# Health Information Systems

Technological and Management Perspectives

Third Edition

Alfred Winter Institute of Medical Informatics, Statistics and Epidemiology Leipzig University Leipzig, Sachsen, Germany

Reinhold Haux Peter L. Reichertz Institute for Medical Informatics of TU Braunschweig and Hannover Medical School TU Braunschweig Braunschweig, Niedersachsen, Germany

Bianca Steiner German Foundation for the Chronically Ill Berlin, Germany

Elske Ammenwerth Institute of Medical Informatics UMIT TIROL - Private University for Health Sciences and Health Technology Hall in Tirol, Austria

Michael Marschollek Peter L. Reichertz Institute for Medical Informatics of TU Braunschweig and Hannover Medical School Hannover Medical School Hannover, Niedersachsen, Germany

Franziska Jahn Institute of Medical Informatics, Statistics and Epidemiology Leipzig University Leipzig, Sachsen, Germany

ISSN 1431-1917 ISSN 2197-3741 (electronic) Health Informatics ISBN 978-3-031-12309-2 ISBN 978-3-031-12310-8 (eBook) https://doi.org/10.1007/978-3-031-12310-8

Leipzig University, Hanover Medical School, TU Braunschweig and UMIT Tirol

© The Editor(s) (if applicable) and The Author(s) 2004, 2011, 2023. This book is an open access publication.

**Open Access** This book is licensed under the terms of the Creative Commons Attribution 4.0 International License (http://creativecommons.org/licenses/by/4.0/), which permits use, sharing, adaptation, distribution and reproduction in any medium or format, as long as you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons license and indicate if changes were made.

The images or other third party material in this book are included in the book's Creative Commons license, unless indicated otherwise in a credit line to the material. If material is not included in the book's Creative Commons license and your intended use is not permitted by statutory regulation or exceeds the permitted use, you will need to obtain permission directly from the copyright holder.

The use of general descriptive names, registered names, trademarks, service marks, etc. in this publication does not imply, even in the absence of a specifc statement, that such names are exempt from the relevant protective laws and regulations and therefore free for general use.

The publisher, the authors, and the editors are safe to assume that the advice and information in this book are believed to be true and accurate at the date of publication. Neither the publisher nor the authors or the editors give a warranty, expressed or implied, with respect to the material contained herein or for any errors or omissions that may have been made. The publisher remains neutral with regard to jurisdictional claims in published maps and institutional affliations.

This Springer imprint is published by the registered company Springer Nature Switzerland AG The registered company address is: Gewerbestrasse 11, 6330 Cham, Switzerland

# **Preface to the Third Edition**

This third edition contains signifcant changes to the book's frst edition in 2004 and also to its second edition in 2011. Of course, there has been progress in the methodology and technology of processing and storing data, information, and knowledge, having an impact on technologies of health information systems and on their management. In addition to this progress, there was an important trend from primarily institution-centered views on information systems, with hospital information systems as the major instance, to patient-centered views on health information systems. When also including prevention as a relevant part of health care, this even leads to person-centered views with the respective requirements.

Having this in mind, the structure of this third edition needed to be changed. We frst had to introduce life situations and their context concerning health and health care in order to understand the various demands on health information systems (Chap. 1). Then, as in previous editions, basic concepts are introduced (Chap. 2). The three main chapters of this book deal with technology perspectives (Chap. 3) and management perspectives (Chap. 4) of health information systems as well as with how to assess their quality (Chap. 5). A new chapter had to be added on information systems for specifc health care and research settings (Chap. 6). Although hospitals and hospital information systems remain highly relevant instances of health care facilities and health information systems, this chapter also includes various other health care facilities as well as medical research institutions. Last but not least, health care settings in personal environments such as a person's home or workplace are considered as well as perspectives concerning transinstitutional health information systems of states and regions. New to this edition are solutions to the exercises. As in previous editions, we included a glossary (in the frst and second edition called a thesaurus), listing all relevant terms introduced and used in this book. Both the solutions to the exercises and the glossary are part of the back matter of the book.

We cordially want to thank everyone who helped us to write this third edition. It is impossible for us to list even the most important persons here, be they users or managers of such information systems, collaborators in projects on health information systems, or decision-makers in health care settings, from politics and from governmental institutions. We would like to express our special thanks to all of our colleagues who contributed to this book and to the colleagues in our working groups and institutes. Thanks as well to the people who contributed to the photos in the book. Not least, we want to thank the students and teachers who use this textbook, in particular those students and teachers who participated in our international Frankvan Swieten Lectures on strategic management in health information systems. Both the students and the teachers kept asking critical questions and drew our attention to incomplete and indistinct arguments.

Finally, we want to note that there was again a change of authors. M.M. and B.S. joined the team of authors. Birgit Brigl and Nils Hellrung asked to step down as their new and demanding responsibilities made it diffcult for them to continue.

Leipzig, Germany Alfred Winter Hall in Tirol, Austria Elske Ammenwerth Braunschweig, Germany Reinhold Haux Hannover, Germany Michael Marschollek Berlin, Germany Bianca Steiner Leipzig, Germany Franziska Jahn

# **About the Book**

#### **How medicine and health care must, should, may, can, and want to act and, accordingly, what health information systems must, should, may, can, and want to support and enable**

For medicine, especially for health care, its self-refective character seems to be of particular importance to me: incorporated into our socio-cultural space, it must always consider in which image of humanity, in which range of cultural values between health and illness, between "normality" and "abnormality," it


With these modalities of action, medicine is not only committed to the present status but also to the prognosis (of current diseases and developments of medicine and society).

Professor Dr. med. Klaus Gahl

From a correspondence with Dr. Gahl in April 2020 (translated from German).

# **Contents**



#### Contents



#### Contents




# **About the Authors**

**Alfred Winter** is a professor of medical informatics at the Institute of Medical Informatics, Statistics and Epidemiology at Leipzig University, Germany. For many years, he was responsible for the strategic management of the information system at Leipzig University Medical Center and led numerous projects in tactical information management.

He studied computer science at RWTH Aachen University in Aachen, Germany, and received his Ph.D. and a license for lecturing (German "Habilitation") for medical informatics from the Faculty of Theoretical Medicine at the University of Heidelberg.

Dr. Winter's research focuses on methods and modeling tools for the management of health information systems and on the integration of information systems for patient care and research. He teaches architectures and management of health information systems in a medical informatics master's course at Leipzig University and as part of the international Frank-van Swieten Lectures on strategic information management. He has been a member of the board of the German Society for Medical Informatics, Biometry and Epidemiology (GMDS) since 2005 and was its president in 2020 and 2021. At the European level, he has been a member of the board and secretary of the European Federation of Medical Informatics (EFMI) since 2014. He is also a member of the editorial board of several international journals and was editor of the German journal *GMS Medical Informatics, Biometry and Epidemiology (MIBE)* from 2010 to 2020. He is an elected member of the International Academy of Health Sciences Informatics.

**Elske Ammenwerth** is a professor of health informatics and head of the Institute of Medical Informatics at the Private University for Health Sciences, Medical Informatics and Technology (UMIT TIROL) in Hall in Tirol, Austria.

She studied medical informatics at the University of Heidelberg/University of Applied Sciences Heilbronn, Germany, and received her Ph.D. from the Medical Faculty of the University of Heidelberg.

Her current research felds comprise health information systems, evidence-based health informatics, and patient-centered health information systems. She has authored or coauthored more than 400 scientifc papers.

Dr. Ammenwerth is the Austrian representative at the European Federation for Medical Informatics (EFMI) and at the International Medical Informatics Association (IMIA). She is an elected member of the International Academy of Health Sciences Informatics.

**Reinhold Haux** Reinhold Haux is a professor of medical informatics at the Peter L. Reichertz Institute for Medical Informatics of TU Braunschweig and Hannover Medical School, Germany. From 2007 to 2017 he served as executive director of this institute.

He studied medical informatics at the University of Heidelberg/University of Applied Sciences Heilbronn, Germany, where he graduated with an M.Sc. degree (German "Diplom") in 1978. He received a Ph.D. from the Faculty for Theoretical Medicine at the University of Ulm in 1983 and a postdoctoral lecture qualifcation (German "Habilitation") for medical informatics and statistics from the Medical Faculty of RWTH Aachen University in 1987.

Dr. Haux's current research felds are health-enabling technologies, health information systems and management, medical data management, and synergy and intelligence: extended interaction of living and non-living entities. The international Frank-van Swieten Lectures on strategic information management in health information systems have been part of his teaching activities since their start in 2001. He has been chairperson or member of information management boards at various hospitals in Germany and Austria.

For the term from 2007 to 2010, he was president of the International Medical Informatics Association (IMIA), an NGO of the World Health Organization. From 2001 to 2015 he was editor of the journal *Methods of Information in Medicine*. He coedited the *IMIA Yearbook of Medical Informatics* from 2001 to 2007.

Dr. Haux is an elected member of the Braunschweig Scientifc Society and of the International Academy of Health Sciences Informatics, where he served as president from 2018 to 2020.

**Michael Marschollek** is a professor of medical informatics and executive director of the Peter L. Reichertz Institute for Medical Informatics of TU Braunschweig and Hannover Medical School, Germany. He studied medicine at Hannover Medical School and computer science at TU Braunschweig, both in Germany, and received an M.D. and a doctoral degree in engineering.

His current research felds include wearable sensors and clinical applications of health-enabling technologies, secondary use of clinical data, data mining in medicine, technologies for semantic modeling of clinical data, and sensor-based activity analysis. He is an elected member of the International Academy of Health Sciences Informatics and of the Braunschweig Scientifc Society. Dr. Marschollek teaches medical informatics for medical students and biomedical data science in a master's program for physicians and life sciences students at Hannover Medical School.

**Bianca Steiner** Bianca Steiner is a research associate/project manager at the German Foundation for the Chronically Ill in Berlin, Germany. She works on various projects focusing on innovations in health care and manages a nationwide quality assurance measure for the quality documentation of recording vital parameters through implanted devices.

She studied medical informatics at TU Braunschweig, Germany. Between 2015 and 2021, she worked as a research associate at the Peter L. Reichertz Institute for Medical Information of TU Braunschweig and Hannover Medical School, focusing on intersectoral care processes and health-enabling technologies in the feld of rehabilitation. In 2021, she received her Ph.D. from the Carl-Friedrich-Gauß-Faculty at TU Braunschweig for her work on increasing therapy adherence in rehabilitation through gamifcation.

Dr. Steiner taught medical informatics students at TU Braunschweig from 2016 to 2021 and since 2019 has also taught information management students at the Hochschule Hannover—University of Applied Sciences and Arts.

**Franziska Jahn** Franziska Jahn has been a research associate at the Institute for Medical Informatics, Statistics and Epidemiology at Leipzig University, Germany, since 2008.

She studied computer science with medical informatics as main subject at Leipzig University. Her research focuses on hospital information system architectures and their management. In recent years, she has led projects concerned with ontologies for information management in health care and benchmarking of hospital information systems.

Dr. Jahn teaches medical informatics students and medical students at Leipzig University. Since 2021, she has also been a lecturer in the Medical Data Science master's program at RWTH Aachen University.

Since 2015, she has been cochair of the Methods and Tools for the Management of Hospital Information Systems working group of the German Association of Medical Informatics, Biometry and Epidemiology (GMDS).

**The Authors**

# **Abbreviations**





# **List of Figures**



#### List of Figures



#### List of Figures


# **List of Tables**



# **Chapter 1 Introduction**

## **1.1 Motivation and Objective of the Book**

Which technologies are appropriate for building *health information systems*? How can they be managed? How to assess their *quality*? The objective of this book is to provide answers to these questions.

Health is one of the key components of our lives. And good health care is an important prerequisite for good health. Well-built and well-managed health information systems constitute an essential part of providing good health care. Health care is delivered for people by people. Health care starts when people are born (even earlier) and ends when people pass away. Sometimes, the relative share of health care in our lives appears negligible, for example, when we are in good health, living our "normal daily lives." Sometimes, the relative share of health care is intensive, for example, for persons suffering from a severe acute disease and as inpatients in hospitals. Sometimes, it is in between, for example, for persons with chronic diseases needing medication or other therapeutic measures on a regular basis.

The authors of this book have been involved in managing health information systems for many years, some of us for decades. Managing *information systems* also includes building and assessing components of such *systems*, as will be explained later. We do this mainly in research and education, but always with close links to practice. We also advise health care facilities as well as governments and other authorities. During all these years, we have seen information systems that contribute well to the diagnosis and therapy of patients by providing good support to *health care professionals* as well as to the patients themselves. We have also seen information systems that produce an unnecessary workload for physicians and nurses or fail to appropriately deliver *information* that would have been relevant for good decisions.

We, the authors of this book, believe that managing health information systems in the current era of digitization must be approached differently than in the past. In particular, in order to provide answers to the questions raised at the beginning, we need an understanding of how information systems in the context of health and health care relate to the various *life situations*.

This is why this introductory chapter is on such life situations and on the (sometimes contradicting) stakeholder requirements. *Stakeholders* in this context include the patients themselves as well as health care professionals and, for example, management staff in health care facilities and governmental bodies.

We are convinced that being aware of these life situations, of the stakeholder requirements, and of the basic concepts and terms introduced in Chap. 2 is of great importance. These two chapters will give you, the reader, a better understanding of the following chapters of this book: Chap. 3 on technology perspectives, Chap. 4 on management perspectives, and Chap. 5 on quality. These more generic chapters will be rounded out by Chap. 6 on specifc health information systems for certain life situations and *health care settings* such as, for example, *hospital information systems* and information systems in personal environments.

After reading this chapter, you should be able to


## **1.2 Life Situations**

As mentioned before, health care starts when people are born (even earlier) and ends when people pass away. Sometimes, the relative share of health care in our lives is small, sometimes it becomes higher. This section provides an overview of some typical life situations.

Health care organization and health-related processes can vary from country to country; however, these life situations seem ubiquitous. We focus on life situations related to health care. This view may be limited, as life is much more, but it is useful for our topic of health information systems.

## *1.2.1 Prevention*

The World Health Organization's constitution defnes health as a state of complete physical, mental, and social well-being [1]. Living in good health is by no means a given; it must be achieved or preserved by respective measures. In health care, many of these measures can be subsumed under the term "prevention" or, more precisely, primary *prevention*. In addition to primary *prevention* (prevention of diseases), the terms secondary *prevention* (early detection and timely treatment of diseases) and tertiary *prevention* (reduction of negative implications of long term, usually chronic diseases) are well established and used. *Prevention* mostly takes place in our normal daily lives, for example, at the locations where we live and work. Tertiary *prevention* may also coincide with rehabilitation.

## *1.2.2 Wellness*

Wellness is a term related to *prevention*, as it also focuses on living in good health. In the context of wellness, the term "ftness" can also be found. Wellness and ftness activities usually take place in our normal daily lives and at the locations where we live and work. Sometimes, wellness activities are done at wellness centers (e.g., hotels that are specialized in this feld). Sometimes, ftness activities are done at sports centers and recreational parks.

## *1.2.3 Emergencies*

Emergency situations such as acute heart attacks or severe traffc accidents are completely different life situations. Persons suffering such emergency situations frequently require immediate assistance. As patients, they are usually brought to the emergency units of hospitals, where they are diagnosed and treated by health care professionals.

## *1.2.4 Acute Diseases*

Persons suffering from acute diseases also step out of their normal daily lives, at least to some extent. With respect to these diseases, these persons have become patients. Depending on the kind and severity of such an acute disease, patients may, among other things, be treated as outpatients in medical offces or as inpatients in hospitals. For outpatients, diagnosis and therapy may take place within these offces or at the locations where the patients live. If diagnosis and therapy are performed at a distance, these activities are usually subsumed under terms "telehealth" and "telemedicine."

## *1.2.5 Chronic Diseases*

The life situations of patients suffering from chronic diseases can be more or less viewed similarly to those described for patients with acute diseases. In chronic situations, long-term treatment and long-term care is needed, and health care monitoring becomes more important here. If this monitoring is done at a distance, these activities are usually also subsumed under the term "telemonitoring."

## *1.2.6 Care*

Life situations primarily related to care but not necessarily related to treating diseases are often characterized by physical and mental functional defcits of the affected persons that could lead to frailty, for example. These are often, but not exclusively, senior citizens at an advanced age. Care may be provided at these persons' private homes, at homes for the elderly, at nursing homes, or, for palliative care, at hospices.

## *1.2.7 Rehabilitation*

In particular after treatment episodes for inpatients, rehabilitation episodes may sometimes follow in order to cure or alleviate diseases. As already mentioned, these rehabilitation activities can often be subsumed under tertiary *prevention*. Rehabilitation may take place at inpatient units or may be supported by outpatient rehabilitation centers. With acute and chronic diseases, this can be done within such centers, or perhaps at a distance through telerehabilitation activities.

## *1.2.8 Research for Life*

Another life situation must be mentioned here that to some extent differs from the ones described above, as it is also of considerable importance for health information systems: the life situation of persons in the context of biomedical research. Patients, or even healthy persons, may participate in research activities. For example, patients may be asked to participate in randomized clinical trials. Or, as another example, *data* on patients may be stored in disease registers to better understand diseases and their diagnosis and therapy in order to improve treatment for future patients.

## **1.3 Stakeholders' Requirements**

As mentioned in the introduction, health care is delivered for people by people. Also mentioned was that stakeholder in this context refers to the patients themselves, as well as health care professionals, the management staff of health care facilities, or even governments. This section lists some of the essential requirements that important stakeholders have regarding health information systems.

Being aware of these stakeholders and their requirements of health information systems is important for adequately managing health information systems. We will list here major stakeholders, either introduced as persons or as bodies. This is not an exhaustive list. The requirements listed here for these stakeholders are important requirements with respect to health information systems. These lists will highlight some important requirements, but by no means all of them.

## *1.3.1 Requirements of Patients*

The patients' objectives are usually to receive good and affordable health care, to be informed and empowered regarding all decisions related to health care and, if possible, to receive this care without having to change their normal daily lives too much, with social participation and dignity as important properties.

Requirements that patients have of health information systems are, mostly, (1) to be informed (e.g., about appointments with their physicians at medical offces, about diseases, about possible diagnostic and therapeutic strategies and their risks, or about positive or negative aspects of medication), (2) to be able to communicate with health care professionals and their facilities (e.g., asking for an appointment, asking for advice), and (3) to be able to provide data or to report (e.g., on unexpected events that may be important to know in the context of their diseases), and (4) to feel suffciently informed and involved when decisions about their individual health care are being taken.

Patients also want to be informed about the qualifcation and reputation of their health care professionals and of their health care facilities. When receiving direct advice on health care matters, for example, through the internet or via health apps, they also want to know about the quality of the care.

Regardless of the persons and facilities providing the care, patients expect all caregivers to have access to all necessary data in their health record (provided the patients give their permission). They also expect data privacy and data confdentiality to be safeguarded.

Finally, patients expect health information systems to support not only themselves but—perhaps even more importantly—to also support their health care professionals and sometimes their informal caregivers and that this support is comprehensive, trustful, and lean.

**Fig. 1.1** Health information systems constitute an essential part of providing good health care. Decisions are made during a ward round in pediatric intensive care. (Courtesy of Karin Kaiser/MHH)

## *1.3.2 Requirements of Health care Professionals*

*Health care professionals* usually are physicians and nurses but may also be pharmacists, physiotherapists, and midwives, just to mention a few. Their objective is to provide good health care for their patients.

Requirements that health care professionals have of health information systems include that these systems support them in doing their work effciently and in good quality. This often involves providing easy and comprehensive access to information in order to make good decisions, with organizational support and with reduced documentation efforts while maintaining good documentation quality (Fig. 1.1).

Having access to all the patient data relevant for adequate diagnostic and therapeutic decisions, for example, is of great importance. If relevant data are missing or if data are diffcult and time-consuming to obtain, this would risk reducing the quality of care and could increase costs.

Additional requirements include being able to effciently record and communicate decisions at the time and place where they were made, receiving decision support, and having access to knowledge on diseases and on how to treat them.

## *1.3.3 Requirements of Informal Caregivers*

Informal caregivers are often spouses or close relatives of the patients. Although they are usually not trained health care professionals, their contribution to caring for patients can be of enormous importance for the quality of health care.

Requirements that informal caregivers have of health information systems primarily include being informed of the treatment provided by health care professionals, having access to the patients' health records (provided the patients give their permission), having the opportunity to communicate with health care professionals, and recording observations.

## *1.3.4 Requirements of Researchers in Biomedicine*

Many researchers in biomedicine need patient data for their research. Provided that patients give their permission or that this is allowed by law, the researchers' objective is to access and use these data for their research. This can be routine data recorded during *patient care* at one or several health care facilities.

Sometimes these data can be aggregated, anonymized data. Biomedical research related to patient data is often conducted as part of studies, for example, clinical trials or observational studies, with a study plan, elaborated before collecting data, and approved by ethics committees.

Requirements that researchers in biomedicine have of health information systems include being supported in doing their work effciently and in good quality, for example, to be able to access, store, and analyze such data with reasonable effort and with the potential of attaining good outcomes for medical progress.

## *1.3.5 Requirements of Management Staff*

Persons involved in managing health care facilities have certain responsibilities related to running their facilities effciently and in good quality with regard to their facilities' objective of providing health care. For this purpose, these persons must document procedures for reimbursement and to ensure the availability of data for *controlling*, this with respect to the sometimes-various levels of health care management.

Requirements that management staff have of health information systems include being supported in doing their work effciently and in good quality. This often involves having timely access to controlling data and being able to effciently use analytics tools in the context of data warehousing.

## *1.3.6 Requirements of Insurance Companies*

At this point, we will shift our view from persons to facilities. Health care insurance companies want to spend the money obtained from their members to provide these members with good and effcient health care when needed. This can involve providing timely payment to health care facilities and *controlling* whether payments have been adequate. This may also comprise informing their members on health care matters and exploring and promoting new, improved health care processes.

Requirements that insurance companies have of health information systems include being able to carry out these tasks effciently and in good quality. Insurance companies want to be able to verify whether payments that were made were actually used for "their" members and that these members were actually insured at the time of treatment.

## *1.3.7 Requirements of Governmental Bodies*

Governmental bodies with tasks related to health care often involve ministries or departments of health. The objectives of such governmental bodies are to provide a legal framework for the health care of the people living in a certain state or region. Sometimes, they are involved in the practice of health care themselves.

Requirements that governmental bodies have of health information systems are that these *information systems* support good health care for the people of their state or region with reasonable costs and that the *information systems* provide data and *key performance indicators (KPI)* about the health status of people in the region or nation.

## *1.3.8 Requirements of Sponsors*

Health care, health care facilities, and the people providing health care need to be fnanced. Financers of health care and of health care facilities will here be called sponsors. Sponsors may be states using taxes paid by their citizens or insurance companies using the premiums paid by their members. Sponsors (private companies, cities, states, etc.) can also own health care facilities such as hospitals.

Sponsors usually expect their facilities or *services* to effciently provide health care that is competitive to facilities delivering related health care and which is fnancially sound. For non-proft sponsors, this can mean running a *health care facility* without fnancial defcits. For commercially oriented sponsors, this can mean that health care facilities should work with a proft for the sponsors' stakeholders.

Requirements that sponsors have of health information systems are that these information systems support the objectives mentioned above for the respective health care facilities and that they provide the data needed for controlling investment costs and running expenses.

## *1.3.9 Requirements of Vendors*

Vendors in this context are companies that offer hardware and software or consulting services for information systems of health care facilities. Vendors may also offer tools or services (on *prevention* and wellness) directly for healthy persons as well as for patients and their informal caregivers (e.g., through the internet and via health apps) and their settings.

The objective of vendors is to sell such tools or services and to be competitive within their respective markets. In addition to providing good products and services, customer retention can also play an important role.

Here requirements of health information systems are rather indirect, as vendors are not users of such systems themselves.

## *1.3.10 Requirements of Housing Companies*

In the new era of digitization, the personal home environment can also play a signifcant role in supporting health care. This is particularly true for persons living at home who receive health care as outpatients, for example, with chronic diseases or as senior citizens with age-related defcits. Housing companies offering the opportunity to use sensor and actor infrastructures within the homes for health care purposes could be more competitive in their market.

Requirements that housing companies have of health information systems are that these information systems support the objectives mentioned above for the respective health care facilities and that they provide opportunities to receive and send data from and to health care facilities and to residents' apps.

## *1.3.11 Coinciding and Contradicting Requirements between Stakeholders*

The requirements of the different stakeholders are sometimes similar and therefore coincide. Other times, however, they tend to confict and may even become contradictory. Being well-aware that requirements of different stakeholders may sometimes vary and may even contradict is helpful when managing health information systems.

The patient-centered objectives on care of governmental bodies, for example, may to some extent contradict the institution-centered objectives of health care facilities and their professionals working in health care and management. The objectives of health care professionals within a health care facility will tend to focus on providing the best health care possible, while managers at the same facility will have a focus on cost effciency and obtaining well-documented data for reimbursement and *controlling*. Sometimes, these contradicting requirements may even exist within the same person, for example, within a family physician at a small medical offce who is responsible for both health care and management.

## **1.4 Example**

The following example will be used in many parts of this book. Although the situations described here are realistic, all persons in this example are fctitious and do not exist.

The Russos live in a fat in a small town on the edge of the commuter belt of a large city. Mrs. Russo, a former optometrist, is 68 years old and—following a fall in the bathroom last year with a fracture of a leg and some complications—suffers from lasting limitations of her movement capacity, affecting her ability to perform some of her activities of daily living (e.g., taking a shower, shopping, meeting with friends). She was also diagnosed with a mild case of depression along with an anxiety disorder. Mr. Russo, a former software consultant, is 72 and, following a myocardial infarction 15 years ago, was diagnosed with heart failure 3 years ago. The Russos' general practitioner (GP), Dr. Andersson, has furthermore diagnosed him with hypercholesterolemia (elevated blood cholesterol) and diabetes and has put him on medication with several drugs. Dr. Andersson also advised Mr. Russo to take up mild physical activity and lose some of his excess weight, but—following a brief episode of motivation and a Nordic walking course—he has found it impossible to follow her advice and sustain regular physical activity, in part because he increasingly needs to help his wife in performing her daily activities.

One morning, Mr. Russo wakes up early in the morning from severe shortness of breath. Although he has experienced this symptom before in a milder form, he immediately senses that something is wrong and calls his GP. Dr. Andersson comes for a home visit and fnds him in bed with low blood pressure, elevated heart rate, and pulmonary edema. She diagnoses him with an exacerbation of heart failure, strongly advises him to be admitted to Ploetzberg Hospital university medical center, and subsequently calls an ambulance. The paramedics arrive and perform a resting 12-lead electrocardiogram (ECG), and the emergency physician puts Mr. Russo on oxygen. After arrival at Ploetzberg Hospital, Mr. Russo is admitted to the cardiology ward and treated with drugs. Blood samples are taken and an echocardiography is performed. His condition improves over a week, but an intracardiac catheter examination (coronary angiography) shows a severe stenosis of a main coronary artery, which is treated immediately. Two weeks later, Mr. Russo is discharged from the hospital and, following a brief stay at home, begins rehabilitation at the Kreikebohm Rehabilitation Centre. Meanwhile, Mrs. Russo's children have organized a home nursing service for her that comes twice a day to support her while her husband is away, along with a domestic help to assist her with the housework.

Dr. Andersson receives discharge letters from both Ploetzberg Hospital as well as the Kreikebohm Rehabilitation Centre. She adapts his medication according to the cardiologists' advice. Along with his wife, Mr. Russo enrolls in a support program arranged by his health insurance company where he uses an app on his mobile phone to enter data on his physical and mental well-being and his weight. Furthermore, he receives an activity tracker that also measures his heart rate. Among other things, Dr. Andersson uses this data to manage the course of his disease and for adapting her treatment. Researchers from Ploetzberg Hospital ask Mr. Russo whether he would participate in a scientifc study to investigate the effect of close-knit home monitoring on rehospitalization in patients with heart failure, to which he agrees. He can observe his monitoring data on his smartphone.

## **1.5 Exercises**

## *1.5.1 Life Situations*

Consider a recent health-related situation you were involved in. Which life situation (Sect. 1.2) does it correspond to and what was your role in this life situation (Sect. 1.3)? List some of the requirements you had in this role and in this life situation.

## *1.5.2 Requirements of Various Stakeholders*

Consider the requirements of various stakeholders when it comes to health information systems supporting various life situations. Can you imagine situations where the requirements of two stakeholder groups differ or even contradict each other? What does this imply when building health information systems?

## **Reference**

1. World Health Organization (WHO) Constitution. (1946, July 22). https://www.who.int/about/ governance/constitution. Accessed 15 Jan 2023.

**Open Access** This chapter is licensed under the terms of the Creative Commons Attribution 4.0 International License (http://creativecommons.org/licenses/by/4.0/), which permits use, sharing, adaptation, distribution and reproduction in any medium or format, as long as you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons license and indicate if changes were made.

The images or other third party material in this chapter are included in the chapter's Creative Commons license, unless indicated otherwise in a credit line to the material. If material is not included in the chapter's Creative Commons license and your intended use is not permitted by statutory regulation or exceeds the permitted use, you will need to obtain permission directly from the copyright holder.

# **Chapter 2 Basic Concepts and Terms**

## **2.1 Introduction**

Health informatics specialists usually deal with ambiguous terms based in computer science, medicine, health sciences, business informatics, and related disciplines. In practice, ambiguous terms lead to diffculties and errors in communication.

One major objective of this textbook is to provide the reader with a clear *terminology*, i.e., a system of concepts and related terms, for health information systems and their management. Such a terminology helps health informatics students, practitioners, and scientists in specifying, describing, and communicating their objectives, tasks, and working results (Fig. 2.1).

This chapter introduces the terminology for health information systems and their management as used in this book. For describing information system architectures for health, we introduce the three-layer graph-based metamodel. It links the logical and physical tools that are used in health information systems to health care functions, which describe the tasks to be performed in certain health care settings, for example, patient admission or execution of diagnostic procedures in a hospital.

To support the learning of the terminology provided in this textbook, some of the authors have developed an ontology called SNIK (semantic network of information management in hospitals) that contains the most important concepts and terms of this book together with their relations to each other.1 In addition, the ontology links our terminology to other terminologies from business informatics and management of information systems. This gives the reader a holistic view of the management of information systems in health and its overlap with other disciplines.

After reading this chapter, you should be able to


<sup>1</sup> https://www.snik.eu.

<sup>©</sup> The Author(s) 2023

A. Winter et al., *Health Information Systems*, Health Informatics, https://doi.org/10.1007/978-3-031-12310-8\_2

**Fig. 2.1** Health information systems constitute an essential part of providing good health care. Agreeing on concepts and terms is the precondition for professionally managing information systems


Please note that the terms highlighted in italics are terms from the glossary or represent functions or application system types (Sects. 3.3 and 3.4).

## **2.2 Data, Information, and Knowledge**

There are several defnitions of *data*, *information*, and *knowledge*. In this chapter, we introduce pragmatic defnitions which help to distinguish the three concepts from each other.

Assume a physician at Ploetzberg Hospital fnds a note on her desk that says "Russo", "8.5", and "++". These characters and numbers written on the note are data.

*Data* are characters, discrete numbers, or continuous signals to be processed in information systems.

*Metadata* is data about data. Metadata provides information about one or more aspects of data such as the purpose of the data, author and time of creation, used standards, or fle size.

Data cannot be interpreted by a person without knowledge about the documentation context. To be reinterpretable, there must be an agreement on how data represent information.

After the physician found the note saying "Russo", "8.5", and "++", she meets a nurse who tells her that the note documents the fasting blood sugar level of the patient Jakub Russo. Now the physician can interpret the note. "Jakub Russo has a fasting blood sugar level of 8.5 mmol/L" is health-related information about the patient Jakub Russo.

There is no unique defnition of information. Depending on the point of view, the defnition may deal with a syntactic aspect (the structure), a semantic aspect (the meaning), or a pragmatic aspect (the intention or goal of information). We want to defne information as follows:

*Information* is a context-specifc fact about entities such as events, things, persons, processes, ideas, or concepts. Information is represented by data.

What does the symbol "++" on the note mean? The physician can interpret this data because she has knowledge about blood sugar levels. She knows that fasting blood sugar levels below 5.5 mmol/L are normal, from 5.6 to 6.9 mmol/L are an indicator for prediabetes, and above 7.0 are an indicator of diabetes.

*Knowledge* is general information about concepts in a certain (scientifc or professional) domain (e.g., knowledge about diseases or therapeutic methods) at a certain time.

Knowledge as general information contrasts with specifc information about particular individuals of the domain (e.g., information about a patient). This means that, due to the physician's general knowledge about diabetes symptoms, she can conclude that Jakub Russo suffers from diabetes, which, in turn, is information about Jakub Russo.

Although a paper note saying "Russo", "8.5", and "++", and its subsequent interpretation, is not an example of systematic data, information, and knowledge processing in health care, it may be helpful to understand the difference between data, information, and knowledge.

However, in the context of health information systems and beyond, it is sometimes diffcult to distinguish between the processing of data and information. Does an *application system* for patient administration process data or information during *patient admission*? Do physicians process data or information when they make a diagnosis? Throughout this book, we use the terms "data," "information," and "knowledge" as precisely as possible and want to emphasize the differences between them. Therefore, the reader should be aware that we have given careful thought to the use of terms containing "data," "information," and "knowledge."

## **2.3 Health care Settings**

In accordance with the World Health Organization (WHO) [1], we regard settings as places, social contexts, or facilities where people actively use and shape the environment and thus create or solve problems. In these settings, life situations take place. Within these life situations, creating and solving problems requires and causes complex *information processing*.

If people actively use and shape the environment and thus create or solve problems in settings related to health care, we call these settings *health care settings*. Cities, villages, private homes, medical offces, hospitals, health care regions, *health care facilities*, and *health care networks* are all health care settings. And again, solving problems related to health care is essentially characterized by intensive information processing.

## **2.4 Systems and Subsystems**

Before considering the details of information systems, let us frst defne the concept of a system.

A *system* is a set of persons, things, events, and their relationships forming an integrated whole.

We distinguish between natural systems and artifcial (human-made) systems. For example, the nervous system is a typical natural system, consisting of neurons and their relationships. An artifcial system is, for example, a hospital, consisting of staff, patients, relatives, and their interactions. If a (human-made) system consists of both human and technical components, it can be called a *socio-technical system*.

A system can be divided into *subsystems* that comprise a subset of the components and the relationships between them. For example, the sympathetic nervous system is a subsystem of the nervous system. A subsystem of a hospital is, for example, a ward with its staff and patients. Subsystems themselves are again systems.

For professionals, however, the term "system" is often not specifc enough and needs to be refned in order to avoid misunderstandings ("If you don't know what it is, call it a system.").

## **2.5 Information Systems**

Focusing on processing, storing, and providing data, information, and knowledge in settings leads to the term "information system."

An *information system* is defned as that socio-technical subsystem of a setting which comprises all data, information, and knowledge processing as well as the associated human or technical actors in their respective data, information, and knowledge processing roles.

As stated above, if a (human-made) system consists of both human and technical components, it can be called a *socio-technical system*. But what does "socio-technical" mean when looking at the information system of a given setting? "Socio" refers to the people involved in data and information processing (e.g., health care professionals, patients, medical or health informaticians), whereas "technical" refers to tools such as computers, software, telephones, and paper-based patient records. Thus, when considering the information system of a setting, the people and tools in this setting are considered only in their role as information processors, carrying out specifc actions following established rules. A physician carrying out *medical admissions* of patients in a hospital, for example, follows established rules for interviewing and examining the patients and documenting their answers in *medical documentation and management systems (MDMS)*.

An information system can be divided into subsystems called *sub-information systems*. For example, the information system of a setting can typically be split into two sub-information systems: the part where computer-based tools are used is called the computer-based sub-information system; the rest is called the non-computerbased sub-information system of the information system. Information systems of health care settings may also be divided by organizational structures (e.g., subinformation system of surgical departments or sub-information system of departments for internal medicine) or by professions (e.g., sub-information system of nursing and sub-information system of medical treatment).

## **2.6 Health Information Systems**

Health information systems support health care professionals working in health care facilities as well as healthy or sick persons in their different life situations. The life situations as introduced in Sect. 1.2 are linked to various health care settings, such as health care facilities, where *prevention*, *patient care*, or rehabilitation are carried out. Such situations are also linked to the personal home environment, where people care for their own health or for the health of their relatives and where they solve health-related problems.

Obviously, health care cannot be considered an isolated procedure taking place in one *health care facility* (e.g., one hospital or one medical offce). Instead, health care is a patient-oriented process encompassing *prevention*, diagnosis, and therapy going beyond the facilities' boundaries and integrating the home environment. The patient-oriented care process thus takes place in networks of different actors. Such actors are, for example, hospitals, medical offces of general practitioners (GPs), pharmacies, rehabilitation centers, home care organizations, and even health insurance companies and governmental authorities. We call these networks health care networks. Health care networks can also be understood as health care settings.

With the defnition of information systems in mind, a health information system can thus be easily defned:

A *health information system (HIS)* is the socio-technical subsystem of a health-related setting which comprises all data, information, and knowledge processing as well as the associated human or technical actors in their respective data, information, and knowledge processing roles.

A health information system that uses computer-based data processing and communication tools is called a *computer-based health information system*. Please note that health information systems typically comprise both computer-based as well as non-computer-based sub-information systems.

If we refer to the information system of a certain health care facility, such as a hospital or a medical offce, we can use the more specifc terms "hospital information system" or "medical offce information system," respectively. The information system of a health care network can be called a *transinstitutional health information system (tHIS)*.

As a consequence of this defnition of a health information system, a health care setting has a health information system from the beginning of its existence. Therefore, the question is not whether a health care setting should be equipped with a health information system, but rather how its performance can be enhanced, for example, by systematically managing it or by introducing state-of-the-art tools.

We will describe health information systems in more detail later in this book, especially in Chaps. 3 and 6. In Chap. 3, we will discuss general characteristics of health information systems. In Chap. 6, we will discuss special characteristics that arise for information systems in specifc (health care) settings.

## **2.7 Information Logistics in Health Information Systems**

The goal of a health information system is to suffciently enable *patient care*, administration, and management. For some types of health care facilities, such as university medical centers, health information systems also have to enable research and teaching.

While managing health information systems, legal and other requirements must be taken into account. Legal requirements encompass, for example, data protection or reimbursement aspects. Other requirements may result from management decisions, such as building a common EHR in a transinstitutional information system.

To suffciently enable *patient care*, administration, and management, health information systems must do the following:


We can summarize this under the term *information and knowledge logistics*.

*Information and knowledge logistics* aims at making the right information and knowledge available at the right time, at the right place, to the right people, and in the right form so that these people can make the right decisions.

So what is meant by the "right place"? Persons responsible for information and knowledge logistics in health information systems must consider various areas of health care settings. Health care networks, for example, can consist of


Who are the "right people" to be provided with the "right information and knowledge"? Obviously, the most important people in a health care setting are the patients and, in a certain respect, their informal caregivers such as spouses or other close relatives. The most important groups of people working in health care settings are physicians, nurses, midwives, pharmacists, administrative staff, technical staff, medical informaticians, or health information management staff and managers. Large facilities, such as university medical centers, are managed by a board of directors.

Within each of these stakeholder groups, different needs and demands on the health information system may exist, depending on the role, tasks, and responsibilities (Sect. 1.3). Ward physicians, for example, require different information than physicians working in service units or in a medical offce. Patients sometimes need similar information as physicians but in a different form.

## **2.8 Functions, Processes, and Entity Types in Health care Settings**

In this book, we want to clearly and unambiguously describe the systems needed to ensure information and knowledge logistics. To do this, we need clear concepts to describe the information and knowledge to be provided, the situation in which it is needed, and the people involved. For this reason, we introduce the concepts of *entity*, *entity type*, function, process, and *role* in this section.

*Entities* are excerpts of the real or conceivable world.

Think back to the "Russo example" from Sect. 1.4. After his stay in the hospital, Mr. Russo's GP Dr. Andersson receives discharge letters from both Ploetzberg Hospital and the Kreikebohm Rehabilitation Centre. The "patient Mr. Russo" and the "discharge letter for Mr. Russo from 2020-08-15" are examples of entities.

An *entity type* is the set of virtual or physical entities that have certain properties in common (e.g., "discharge letter" or "patient").

Entity types form a "unit of thought" when talking about similar entities. Thus, both the discharge letter for Mr. Russo and a discharge letter for another patient, Mrs. Smith, belong to the same entity type "discharge letter" and share the same properties such as sending date, author, and recipient.

For the sake of simplicity, we sometimes take entity types as representatives of the covered entities and their data. If, during certain information-processing activities (e.g., admitting patients), data on entities (e.g., name of patients' hometown) is used and interpreted, we simply say that the entity type "patient" is used during *administrative admission* of a patient. In this sense, the entity type "discharge letter" is updated during *medical discharge*. We will also simply say "data on entity type X" if we mean the data describing entities of entity type X (e.g., "data on entity type 'patient'" means data on patients).

An *information-processing function* is the class of similar activities which update or use entity types. Due to their similarity for all patients in a health care facility, the above-mentioned information-processing activities *administrative admission* and *medical discharge* can be considered information-processing functions.

An *information-processing function* (short: *function*) is a directive in a health care setting on how to use data on entity types and how to update data on entity types. An information-processing function has no defnitive beginning or end.

Functions are ongoing and continuous. They describe what is to be done, not how it is done. Functions describe which data on entity types are used to perform the function and which data on entity types are updated by the function.

Functions are performed by human or technical actors.

One can also understand functions as tasks of an actor. But not every task of an actor is an information- processing function. It is only an information-processing function if data on one entity type is used and, after processing this data, the data on another or on the same entity type is updated. For example, a clerk who performs the function *administrative admission* in a hospital needs to ensure that the patient's administrative data, i.e., the patient's name, contact data, insurance data, and personal identifers, are up to date when the patient is admitted to the hospital. The entity type representing patients and their administrative patient data is simply called "patient." During *patient admission*, the clerk may


Thus, we can state that the function *patient admission* updates and uses the entity type "patient."

Functions are usually denoted by nouns or gerunds (i.e., words often ending with -ing or -ion), for example, care planning or *patient admission*.

Functions can be structured into a hierarchy of functions, where a function can be described in more detail by refned subfunctions. For example, *nursing admission* can be seen as a subfunction of *patient admission*. There are different opportunities of refning functions that are further described in Sect. 2.14.

An *activity* is an instantiation of a function. For example, "the physician admits the patient Mr. Russo" is an activity of the function *patient admission*. In contrast to functions, activities have a defnite beginning and end.

To describe how a function is performed may require not only information about its subfunctions but also information about their chronological and logical sequence. This information is described by *business processes*.

*Business processes* describe the sequence of activities together with the conditions under which they are performed.

Business processes are usually denoted by verbs which can be followed by a noun (e.g., "admitting a patient," "planning care," or "writing a discharge letter").

Instances of a business process are composed of the individual activities; hence, they also have a defnite beginning and end. While functions concentrate on the "what," business processes focus on the "how" of activities. Functions can be considered representatives of business processes. For example, there is the function *patient admission* and the business process *patient admission* in a hospital. The function *patient admission* is specifed by the entity types used and the entity types updated when a patient is admitted. The corresponding business process describes the activities of *patient admission* in their chronological and logical sequence.

For both functions and processes, it is necessary to know who is responsible for them or who performs them. The concept of a role summarizes all the stakeholder groups and groups of people working in health care settings.

*Roles* describe the sum of expectations addressed to persons or groups of persons.

Roles can also be regarded as a surrogate for the set of functions to be performed by a person or group of persons together with the resulting duties and the rights needed to perform the functions.

Typical roles in health care settings are ward physician, head nurse, project manager, or *chief information offcer* (CIO).

The term "information-processing function" presented in this section is related to the term *enterprise function* from business informatics. *Enterprise functions* mainly emphasize the contribution of activities to *business goals*, whereas functions, in the meaning presented here, emphasize the information- processing aspects of activities.

## **2.9 Application Systems, Services, and Physical Data Processing Systems in Health Information Systems**

Whereas functions describe what is done, we now want to look at how information, knowledge, and data processing is done. We will thus take a closer look at tools for data, information, and knowledge processing, in particular *physical data processing systems* and *application component*s.

Physical data processing systems ensure the storage, manipulation, and communication of data.

Most people would intuitively call such systems the physically touchable hardware of an information system or physical tool. Physical data processing systems are able to receive, store, forward, or purposefully manipulate data. We denote receiving, storing, forwarding, and purposefully manipulating data as data processing.

Physical data processing systems can be human actors (such as the person delivering the mail), non-computer-based *physical tools* (such as forms for nursing documentation, paper-based patient records, fling cabinets, or telephones), or *computer systems* (such as terminals, servers, personal computers (PCs), or tablets). Computer systems can be physically connected via data wires, leading to physical networks.

A *physical data processing system* is a physical entity that is able to receive, store, forward, or purposefully manipulate data.

For the administration of physical data processing systems that are computer systems, it can be useful to abstract from single pieces of hardware and instead focus on the optimum use of available processing power, storage, or network capacity. For this reason, the technique of hardware virtualization has found its way into data processing centers in recent years. Virtualization software can help simulate the behavior of servers, storage, and networks. Virtual servers (or virtual machines), for example, simulate the functionalities of physical servers. To install different software products which require different operating systems, virtual servers that run on one physical server can be used. By contrast, in a server cluster, different servers could alternatively, depending on their capacity, run a certain application system. The server cluster, however, can be managed as one (virtual) server.

Virtualization techniques to simulate computer systems are widely used in professional health care settings. When using the term "physical data processing systems" in this book, we include their possible implementation as simulated computer systems, i.e., as simulated physical data processing systems such as virtual machines or server clusters.

A computer system is useless without software. Software can be considered as explicit rules for processing the data in a computer system.

An *application software product* is an acquired or self-developed piece of software that can be installed on a computer system.

By installing and customizing an application software product on a computer system and customizing it to the users' needs, application systems (computer-based application components) are created.

An *application system* is the installation of a certain application software product on a certain computer system. It supports certain functions of a health care setting or communication between other application systems and can store and communicate data on certain entity types.

Application systems may be described by the functions they support and by the *features* they provide. *Features* are functionalities offered by the application software product of the application system which directly contribute to the fulfllment of one or more functions. The fner the granularity of a function, the greater is the probability that the function semantically corresponds to a feature offered by an application system.

We denote features by a short phrase consisting of at least one verb and one noun expressing the ability of the application software product.

For example, the application system *patient administration system* stands for the installed application software product to support the functions *patient admission* and *administrative discharge and billing* in a hospital. It may offer the features "generate a unique *patient identifcation number*" (PIN) and "provide catalog of diagnoses" in order to fulfll the functions *patient admission* and *administrative discharge and billing*. Other typical application systems are the *medical documentation and management system (MDMS)*, the *computerized provider order entry (CPOE) system*, and the *picture archiving and communication system (PACS)*. These and other application systems are discussed in more detail in Sect. 3.4. Application systems store data in database systems. Depending on the architecture style of a health information system, each of its application systems either has its own database system or uses the database system of another application system (Sect. 3.5).

Even in highly computerized health care settings, not every informationprocessing function is supported by an application system. Sometimes, the rules for processing data are not implemented as executable application software product but as organizational rules or working plans that describe how people use certain physical data processing systems. For example, the rules regarding how, by whom, and in which context given forms for nursing documentation have to be used in a certain hospital may be described verbally as text in a handbook of this hospital. In this example, the paper-based forms that are used represent physical data processing systems. We call sets of organizational rules for data processing which are implemented by non-computer-based physical tools "non-computer-based application components." They are often also denoted as *paper-based application components*.

"Application component" is an abstract concept for both application systems and non-computer-based application components.

An *application component* is a set of implemented rules which control data processing of certain physical data processing systems. It supports certain functions of a health care setting or communication between application components.

For those dealing with the management of an information system, it is important to have an overview of the information system's application systems. However, users often do not know which application systems they are using. They are merely interested in certain features provided on a website or by an app on their smartphone. The actual application system providing these features may even be hidden from the users and invoked by another application system. We call these features that are provided by one application system for use by another application system and which are thus not immediately used by users "services." Using a service means invoking it.

A *service* is an encapsulated feature provided by application systems in order to be invoked by other application systems.

Details on the most relevant tools for data, information, and knowledge processing, i.e., application components, services, and physical data processing systems, in health care settings can be found in Sect. 3.4 and the following sections.

## **2.10 Electronic Health Records as a Part of Health Information Systems**

The most important functions of health care settings are related to *prevention*, diagnostics, therapy, and rehabilitation. Obviously, data and documents that are relevant to medical decision-making both in diagnostics and in therapy need to be collected and presented in a record for the patient.

Until just a few years ago (and in some cases still in the present), many documents in the records have been paper-based documents, such as laboratory results or discharge summaries. The portion of documents created and stored in computerbased application systems has increased, however, in recent years and will continue

to increase further. It therefore seems natural to strive for a record that is used and updated by application systems and stored in database systems: *the electronic health record (EHR)*.

The *electronic health record (EHR)* is the collection of a person's health data from different health care settings. It is stored by one or more application systems in a transinstitutional health information system (tHIS).

This means that the EHR for a person might be scattered physically across the database systems of multiple (discrete or interconnected) application systems at various health care facilities. Each of the database systems will hold and manage a partial EHR containing partial patient information or, to be more precise, containing data about patient-specifc entity types. Each partial EHR is scoped according to the person's stays at the health care settings which will be discussed in Sect. 3.5.

EHRs provide relevant information about a person whenever and wherever it is needed during *patient care*. Furthermore, EHRs provide information that is relevant for administrative functions, such as *billing* and *quality management*.

An *electronic patient record (EPR)* is the collection of a person's health data from one certain health care facility where the person is or has been a patient. They are stored by application systems designated for this purpose by the facility.

Some years ago, EPRs were the predominant form of electronic records in health care. Hence, potentially relevant information about the medical history of a patient that was recorded in one facility was missing or had to be recorded again in another facility. This led to quality and effciency problems.

Although this situation can still be found in many facilities, efforts are being made today to organize EPRs as patient-centric, i.e., independent of boundaries of facilities, which will transform the multiple EPRs to one EHR for one person.

Different strategies can be found to achieve the vision of a complete and lifetimespanning EHR that supports health care on the one hand but respects legal and ethical issues on the other. These are described further in Chap. 3.

In the international literature, the terms EHR and EPR are usually defned as presented here. In some countries, however, the use of these terms may differ. According to the German data privacy law, for example, health insurers are obliged to provide their insured persons with the so-called electronic patient record (EPR) which contains selected patient data from different facilities. This "EPR," in fact, corresponds more to our defnition of an "EHR."

## **2.11 Architecture and Infrastructure of Health Information Systems**

The *architecture* of an information system describes its fundamental organization, represented by its components, their relationships to each other and to the environment, and by the principles guiding its design and evolution [2].

The architecture of an information system can be described by functions, business processes, application components, services and physical data processing systems, and their mutual relationships.

There may be several architectural views of an information system, e.g., a functional view looking primarily at the functions or a process view looking primarily at the business processes. Architectures that are equivalent with regard to certain characteristics can be summarized in a certain *architectural style*.

The set of components of the information system and services, which are centrally coordinated and provided for use throughout the health care setting, is called the *infrastructure of an information system*. The infrastructure of an information system consists of physical data processing systems such as servers set up centrally in a data center as well as printers and scanners made available for all users at central locations. The infrastructure may also contain *logical tools* such as central application systems that have to be used by most of the users throughout the health care setting. Moreover, the service desk providing support for all users in the health care setting is also part of the infrastructure. Components and services that are dedicated only to a specifc department are not considered to be part of the infrastructure [3].

## **2.12 Management of Information Systems**

Information systems need systematic management. In general, management comprises all leadership activities that determine the goals, structures, and behaviors of a setting. Management as a task includes *planning*, *directing*, and *monitoring* a specifc object. Within a setting, management can focus on different aspects and objects of the setting. In companies, for example, a distinction is made between management of fnances and management of personnel. Accordingly, there is the management of a setting's information system.

*Management of information systems* (short: information management) means


The goal of managing information systems is systematic information processing that supports information and knowledge logistics and therefore contributes to the setting's strategic goals (such as effcient *patient care* and high satisfaction of patients and staff in a health care setting). *Management of information systems* therefore directly contributes to the setting's success and the ability to compete.

*Management of information systems* encompasses the management of all components of the information system—the management of functions, processes, and entity types, of application components and services, and of physical data processing systems.

*Management of information systems* is discussed in detail in Chap. 4.

## **2.13 Modeling Information Systems**

Modeling health information systems is an important precondition for their management: What we cannot describe, we usually cannot manage adequately. But what is a model?

A *model* is a description of what the modeler believes to be relevant about a system.

In the sciences, models commonly represent simplifed depictions of reality or excerpts of it. Models are adapted to answer certain questions or to solve certain tasks. Models should be appropriate for the respective questions or tasks. This means that a model is only "good" when it is able to answer such a question or solve such a task. For example, a model that only comprises the patients (and not the nurses) of a ward cannot be used for nurse staffng and shift planning. Since we are dealing with *management of information systems*, this means that models should present a simplifed but appropriate view of a health information system in order to support *management of information systems*.

Examples of respective questions that can be answered by specifc information system models could be:


The better a model assists its users in answering a given question, the better the model is. Thus, the selection of the adequate model depends on the problems or questions to be answered or solved.

There exists a large number of different classes of models. Each class of models is determined by a certain metamodel. A metamodel can be understood as a language for constructing models of a certain class and a guideline for using the language.

A *metamodel* is a modeling framework which consists of


Just as there are different views on health information systems, there also exist various metamodels. Typical types of metamodels are as follows:


*units* or roles and their hierarchies. Examples of organizational metamodels are organizational charts (also called organigrams).


Modeling of health information systems is based on the right selection of a metamodel. For health information system modeling, you should therefore consider the following steps:


Especially step 3 of gathering the information needed for modeling is often timeand cost-intensive.

Modeling patterns which can be customized to the specifc situation to be modeled can reduce the modeling effort. We call these types of models *reference models*. According to the metamodel used, a reference model supports the construction of models of a certain class of systems and helps to deal with a certain class of questions or tasks concerning these systems.

A model is called a *reference model* for a certain class of systems and a certain class of questions or tasks dealing with these systems if it provides model patterns supporting


A specifc model may be considered a variant of a generic reference model developed through specialization (modifcations, limitations, or completions). This variant is an instance of the metamodel that also underlies the corresponding reference model. For example, a model of the processes in a hospital information system of a specifc hospital may be derived from a general reference model on health information system processes. Both the specifc model and the reference model used are instances of the same business process metamodel.

A reference model should be followed by a description of its usage, for example, how specifc models can be derived from the reference model or how it can be used for the purpose of comparison.

Specifc models can be compared with a reference model, and consequently models can also be compared with each other, judging their similarity or difference when describing certain aspects.

Reference models can be normative in the sense that they are broadly accepted and have practical relevance. Reference models are more likely to be accepted if they are not only reliable and well-tested but also recommended by a respected institution. For example, the initiative Integrating the Health care Enterprise (IHE) (Sect. 3.7.2.5) provides a comprehensive set of models describing how to use communication standards such as Health Level 7 (HL7) and Digital Imaging and Communications in Medicine (DICOM) in typical health care settings. These models can be regarded as reference models. Many experts in the feld use these reference models as norms or standards although they are explicitly not. These models apparently became normative because they are widely used especially in commercial invitations of tenders for software supporting radiology departments.

In the following section, we introduce the 3LGM2 as an information system metamodel that integrates aspects of functional metamodels, technical metamodels, organizational metamodels, and data metamodels. For 3LGM2 , there are also reference models describing certain aspects of health information systems available (Sect. 3.11.1).

#### **2.14 3LGM2 : A Metamodel for Information System Architectures**

The *three-layer graph-based metamodel (3LGM2 )* is a metamodel for modeling (health) information systems. It aims to support the systematic management of health information systems and especially the structural quality assessment of information processing in health care settings. We will use this metamodel further on in this book (especially in Chaps. 3 and 6) and thus present it in detail here.

Typical questions to be answered with models derived from the 3LGM2 metamodel are as follows:


3LGM2 combines functional, technical, and organizational aspects with certain aspects of data and process metamodels. As the name indicates, the 3LGM2 distinguishes three layers of information systems:


The following sections provide a user-oriented description of the three layers, complemented by examples from health information systems.

## *2.14.1 Domain Layer*

The *domain layer* of a 3LGM2 model describes what kinds of activities in a health care setting are enabled by its information system and what kind of data is stored and processed. This layer is independent of the implemented physical and logical tools for data and information processing.

Information-processing activities at a certain time and place in an information system use certain data in order to create, update, or delete other data. For example, the clerk entering Mr. Russo's administrative data into the *patient administration system* when he arrives at the Kreikebohm Rehabilitation Centre creates or updates Mr. Russo's patient data. For the sake of simplicity, we will from here on subsume creating, updating, or deleting patient data under the term "updating."

In Sect. 2.8, we already introduced the important concepts for the domain layer, namely entities, entity types, and information-processing functions. Entities are excerpts of the real or conceivable world, such as "patient Mr. Russo," while an entity type (such as "patient") is a set of virtual or physical entities that have certain properties in common. An information-processing function (short: function) is a directive in a health care setting on how to use data on entity types and how to update data on entity types (such as *care planning* or *patient admission*). At the domain layer, we now use these concepts for health information system modeling to describe entity types, functions, and the relationships between functions and entity types performed in a health care setting.

Figure 2.2 shows an example. The function *administrative admission* updates the entity type "patient," which represents a patient's administrative data. This indicates that during the *administrative admission*, patient data such as name, birthdate, insurance data, and identifcation numbers are documented for the frst time or updated. The entity type "patient" is used by the function *medical admission* which indicates that during a *medical admission*, the administrative data is available and can be used. *Medical admission*, in turn, updates the patient's "medical history." This indicates that information on the medical history is documented or updated during *medical admission*. Both the entity types "patient" and "medical history" are needed to create a medical care plan. Therefore, these two entity types are used by the function *medical care planning*. In 3LGM2 models, functions are represented by rectangles and entity types are represented by ovals.

Functions and entity types can be structured hierarchically by "specialization" and "decomposition." When a function or an entity type is specialized, all its subelements are a refnement of the function or the entity type and independent of the respective super-element. For a function, this means that the activities regarding this function are performed differently in different contexts. The function "execution of

**Fig. 2.2** 3LGM22 representation of functions (represented by rectangles) and entity types (represented by ovals) at the domain layer of 3LGM22. An arrow pointing from a function to an entity type represents an updating access of an entity type. An arrow pointing from an entity type to a function represents a using access of an entity type

diagnostic procedures," for example, has different specializations in different diagnostic departments. Similarly, an entity type can have different forms for slightly different purposes: A radiologic fnding is different from a laboratory fnding; but both are specializations of fndings, which is the generalized term (Fig. 2.3).

By contrast, when a function or an entity type is decomposed, all its subelements form a proper subset of the function or the entity type. An activity regarding a function is only completed if all activities regarding all its decomposed subfunctions are completed. For example, the activities regarding *patient admission* are only completed if *appointment scheduling*, *patient identifcation*, *administrative admission*, *medical admission*, *nursing admission*, and *visitor and information services* have been performed (Fig. 2.4). Similarly, a decomposed entity type is only complete when all its subordinate entity types are available. The entity type "patient," for example, must contain a name, a PIN, the patient's address, and insurance data.

Both decomposition and specialization are represented by dashed arrows from sub-elements to super-elements in 3LGM2 . For modelers, it is important to differentiate between specialization and composition at the domain layer. To avoid misunderstandings, it might be useful to predefne the use of only one hierarchical relationship for functions or entity types in one model. If this is not possible, one should at least consider that an entity type or a function cannot be specialized and decomposed at the same time.

Using relationships and updating relationships between functions and entity types are inherited to their sub-elements, no matter whether the functions or entity types were decomposed or specialized. This means, for example, that the PIN, which is a sub-element of the entity type "patient," may be updated by the functions *patient identifcation*, *administrative admission*, etc. although the "update" relationship is only modeled between the super-ordinated entity type "patient" and the respective functions.

**Fig. 2.4** 3LGM2 representation of a decompositions of the function *patient admission* and of the entity type "patient"

Functions are usually performed in certain parts of health care settings. The execution of radiologic procedures, for example, is performed in the radiology department of a hospital. We call those parts of health care settings "organizational units."

An *organizational unit* is a part of a facility which can be defned by responsibilities.

Organizational units such as a radiology department can be decomposed, but not specialized.

Functions, entity types and organizational units are part of a static view of a health care setting. For modeling the dynamic view of health care settings, business process models are more appropriate. Which entity types and which functions of an information system are modeled depends on the health care setting and on the modeling purpose. Reference models may offer recommendations on important entity types and functions for certain kinds of hospitals.

## *2.14.2 Logical Tool Layer*

#### **2.14.2.1 Application Systems**

At the *logical tool layer*, application systems or, in a broader sense, application components are the center of interest. As defned in Sect. 2.9, an application system is the installation of a certain application software product on a certain computer system. Application components as a more general concept are sets of implemented rules that control data processing of certain physical data processing systems. Application systems as well as non-computer-based application components support functions.

An application system cannot be bought in a shop but must be constructed by customizing a buyable application software product onsite. A *patient administration system*, for example, is implemented by an application software product offering features for *appointment scheduling*, *patient identifcation*, checking for readmitted patients, and *administrative admission*. Many application software products developed for health care facilities consist of different modules, and buyers can decide which of the modules of the application software product they purchase. Application software products for *enterprise resource planning systems (ERPS)*, for example, may offer modules for *human resource management*, *material management*, *fnancial accounting*, and *customer or patient administration* (Fig. 2.5).

Non-computer-based application components are controlled by rules which we can understand as working plans describing how people use non-computer-based data processing systems to support a given function. A working plan may be available in written form in a document (e.g., in an SOP—standardized operating procedure). In most cases, however, working plans are verbal agreements or are merely specifed implicitly. A non-computer-based application component for patient data privacy forms, for example, may be controlled by a working plan that describes when and how to hand out paper-based data privacy forms to the patients and where and how to archive the signed document.

Application components of an information system are objects that are recognized and used by staff members in a facility. But nevertheless, they are not tangible in the same way as physical tools are. We therefore refer to application components also as *logical tools*. Consequently, we call the layer describing the application components the logical tool layer. This is in contrast to the tangible tools, which we refer to as physical.

**Fig. 2.5** 3LGM2 representation of the application system *enterprise resource planning system* which consists of four sub-application systems and a database system and of the paper-based "patient data privacy form system" as non-computer-based application component

At the logical tool layer, application components are responsible for supporting functions and for storing and communicating data on certain entity types. *Computerbased application components* usually store data in database systems which are controlled by database management systems. Non-computer-based application components use document collections for data storage.

Both application systems as well as non-computer-based application components are represented by rounded rectangles at the logical tool layer of a 3LGM2 model. Visually they can be distinguished by different coloring and the different symbols for database systems (cylinders) and data collections (dashed rectangles, Fig. 2.5).

For communication between two application systems, we distinguish between the message-oriented and the service-oriented communication paradigm, which are explained in the following sections.

#### **2.14.2.2 Message-Oriented Communication**

For message-oriented communication, application systems use *communication interfaces*. A communication interface can either send or receive messages over communication links. A *patient administration system*, for example, may communicate with an *MDMS* by sending messages over communication interfaces and a communication link (Fig. 2.6). In this example, the message may comprise information on the admission of a patient and the related administrative patient data.

A *message* is a set of data on entities (e.g., administrative data on a given patient) that are arranged as a unit in order to be communicated between application systems. A message type describes a class of uniform messages and determines which data on which entity types is communicated by a message belonging to this message type. For example, the message type "patient administrative data" could describe how the administrative data on a patient (name, address, identifcation number, insurance data, etc.) must be arranged in a uniform way in order to be understood by both the *patient administration system* and the *MDMS*.

A message type can belong to a communication standard, i.e., a standard for *syntactic interoperability* (Sect. 3.7.1). There are several communication standards which describe how messages of a certain data format must be communicated between application systems. In medical informatics, Health Level 7 Version 2 (HL7 V2) and DICOM are well-known examples of such message-oriented

**Fig. 2.6** 3LGM2 representation of a *patient administration system's* communication interface (represented by a circle) sending messages to a *medical documentation and management system's* communication interface over a communication link (represented by an arrow)

communication standards (Sects. 3.7.2.1 and 3.7.2.4). Application systems have to communicate by using their interfaces to ensure that functions can use and update entity types as described at the domain layer.

The concept of a message-oriented communication paradigm may also be used to model the communication between application systems and non-computer-based application components.

#### **2.14.2.3 Service-Oriented Communication**

The service-oriented communication paradigm assumes that application systems provide encapsulated features ("services") that can be used by other application systems. A *patient administration system*, for example, could offer a service "get patient" to other application systems within a health care facility. When invoking this service, an application system such as the *MDMS* can request and obtain the administrative patient data of a given patient from the *patient administration system*.

Application systems need "providing interfaces" to provide services to other application systems and "invoking interfaces" to invoke services provided by other application systems. In 3LGM2 models, invoking interfaces are represented by circles and providing interfaces are represented by triangles (Fig. 2.7).

Services themselves are not graphically represented at the logical tool layer but can be assigned to interfaces. Services of a similar type can be summarized in 3LGM22 service classes.

A function can be either supported by one service or by a set of combined ("orchestrated") services. In health information systems, the *interoperability standards* HL7 FHIR (Fast Health care Interoperability Resources) and open Electronic Health Record (openEHR) support the implementation of *service-oriented architectures (SOA)*.

Communication with non-computer-based application components can take different forms and is therefore considered separately.

Communication of data between two non-computer-based application components is only possible through an active human intervention, for example, by carrying a paper document from one place to another.

In a similar way, human intervention is necessary for the communication between non-computer-based application components and application systems. Scanning a paper form for archiving or typing a discharge letter which is available as an audio recording are examples of communication from a non-computer-based application

**Fig. 2.7** 3LGM22 representation of a situation where the *patient administration system* provides a service "get patient" invoked by the *medical documentation and management system*

**Fig. 2.8** Communication between an application system and a non-computer-based application component

component to an application system. Printing out a paper form available in the *MDMS* or storing radiological images on a memory device to be taken to another health facility by a patient are examples of communication from an application system to a non-computer-based application component. Figure 2.8 shows the 3LGM2 representation of such "media breaks" between application systems and non-computer-based application components. The details of the communication should be modeled by messages (Sect. 2.14.2.2).

## *2.14.3 Physical Tool Layer*

The *physical tool layer* describes physical data processing systems and their data transmission links among each other. As defned in Sect. 2.9, a physical data processing system is a physical entity that is able to receive, store, forward, or purposefully manipulate data.

For the computer-based part of information systems, servers, PCs, notebooks, tablets, switches, routers, smartphones, etc. are modeled at the physical tool layer. In addition, virtualized physical data processing systems are modeled at the physical tool layer because they behave like physical data processing systems to the outside world (Sect. 2.9).

For the non-computer-based part of information systems, human actors (such as persons delivering mail) and non-computer-based physical tools (such as printed forms, telephones, books, paper-based patient records, administrative stickers) are modeled at the physical tool layer.

Figure 2.9 shows a simple model of the physical tool layer. A virtualized server farm is represented by one physical data processing system. This "black box" is connected to a patient terminal, a PC and a tablet PC. The physician uses both a tablet PC and a telephone as physical computer-based or non-computer-based tools, respectively.

Depending on the modeling goals, health professionals, patients, or caregiving relatives can be modeled as physical data processing systems (as in Fig. 2.9) to highlight their information-processing role in the health information system. In most cases, this will not be necessary.

To specify the relationship between physical data processing systems and virtualized physical data processing systems in a 3LGM2 model, a "virtualizes" relationship can be modeled. Figure 2.10 illustrates the 3LGM2 representation of

virtualization techniques. In a server cluster, physical data processing systems can run certain application systems alternatively. Virtual machines allow multiple operating systems or different instances of one operating system to run on one physical data processing system (compare Sect. 2.9).

Physical data processing systems such as a specifc server or a specifc PC can be assigned to a "tool class" (e.g., server, PC) and a location.

Physical data processing systems are physically connected via data transmission links (e.g., communication network, courier service) which can use different transmitting media. A transmitting medium is either signal-based (e.g., copper cable, optical fber) or non-signal-based (e.g., sheet of paper, CD-ROM, USB fash drive).

Physical data processing systems can be refned by decomposition. A physical data processing system can be part of exactly one physical data processing system. Thus, the lower part in Fig. 2.10 does not show a decomposition but a virtualization.

## *2.14.4 Inter-layer Relationships*

A variety of dependencies, called inter-layer relationships, exist among concepts of the three layers of a 3LGM2 model. Relationships exist between concepts of the domain layer and the logical tool layer and between concepts of the logical tool layer and the physical tool layer.

The following relationships between the domain layer and the logical tool layer can be modeled in 3LGM2 :


Between the logical tool layer and the physical tool layer, there are two types of relationships expressing that application components need certain physical data processing systems to work:


#### *2.14.5 First Steps of 3LGM2 Modeling*

#### **2.14.5.1 Installation of the 3LGM2 Tool**

To start modeling, the current version of the full version of the 3LGM2 tool can be downloaded from http://www.3lgm2.de. The Java-based tool runs on different platforms and can freely be used for non-commercial purposes.

#### **2.14.5.2 Modeling the Domain Layer**

The main elements of the domain layer are entity types and functions. When modeling a domain layer from scratch, the following rules should be observed:


Identifying appropriate functions and entity types for a specifc health care setting is a non-trivial task. The most elaborate but also the most direct way to identify functions and entity types of a setting is to conduct interviews with the persons performing the functions. Preparing and conducting these interviews, function patterns, or reference models providing lists of typical functions and of relationships between the functions of a specifc type of health care setting may be helpful. In Chap. 3, we develop patterns for functions that are performed in many health care settings. These patterns as well as a reference model for the domain layer of hospital information systems are available at http://www.3lgm2.de and can be used and refned for modeling a specifc health information system.

#### **2.14.5.3 Modeling the Logical Tool Layer**

The logical tool layer describes the application components of a health care setting and the communication between these components. For modeling the logical tool layer, the following rules should be observed:


To obtain a correct representation of a logical tool layer, it is in most cases not suffcient to interview health care professionals who work within the health information system. They often have too little insight into the technical details of the logical tool layer. Interviewing information management staff or analyzing the current documentation of the information system are the most promising methods for obtaining information about the logical tool layer of a health care setting.

#### **2.14.5.4 Modeling the Physical Tool Layer**

Physical data processing systems and their connections are modeled at the physical tool layer. This layer has the fewest modeling rules. Depending on the purpose, the modeler must decide whether to model single physical data processing systems such as servers and PCs or to provide a more abstract view, for example, by modeling the data processing center of one facility as one physical data processing system.

Information about the physical data processing systems and the network can be obtained from the staff of the information management department or the data processing center, respectively.

#### **2.14.5.5 Modeling Inter-layer Relationships**

Functions are to be connected with application components supporting them in a health information system. To establish this relationship between the domain layer and the logical tool layer, the organizational unit where the function is supported by the application component should be specifed. This is especially important if a function is supported by one or more application components in a health care setting. Therefore, even if one of these application components fails, this function could still be performed, at least in selected organizational units. In this case, we have a functional redundancy which may be an indication for superfuous application components.

There are also desired functional redundancies. To update the application software product of an application system, it might be necessary to shut down an application system for a few hours. If this concerns an application system which is permanently in use, such as an *MDMS*, it can be helpful to have an evasive application system.

However, we must also be careful that supposed functional redundancy does not result from inaccurate modeling.

In a 3LGM2 model, we specialize or decompose functions to that level of detail needed to describe the support of the functions by single application components. That means if we think of the hierarchy of functions in a 3LGM2 model as a tree in graph theory, then each of the tree's "leaf functions" must completely be supported by one application component of the information system. We only assign application components to the "leaf functions" of the tree. For example, if we fnd that the function *medical and nursing care planning* needs joint support of two application components X and Y, we have to specialize or decompose the function in such a way that the resulting subfunctions are supported by X and Y, respectively. If X is used by clinicians and Y is used by nurses, a solution could be to decompose the function into *medical care planning* and *nursing care planning*.

Besides the relationship between functions and application systems, it is important not to forget to model the relationships between entity types of the domain layer and their representation forms at the logical tool layer (message types, parameters, dataset types).

Between the application systems at the logical tool layer and the physical data processing systems at the physical tool layer, the relationships have to be modeled—both for expressing the installation of an application component on a physical data processing systems and for the storage of data in such a system.

## **2.15 Example**

For this example, we merge many of the small examples of Sect. 2.14 into one 3LGM2 model showing a section of the information system of a fctional hospital. Figure 2.11 illustrates which logical and physical tools are used for the function *patient admission* in the hospital. Four subfunctions of *patient admission* (*appointment scheduling*, *patient identifcation* and checking for readmitted patients, *administrative admission*, and *visitor and information services*) are supported by the *patient administration system*, which is a part of the *ERPS*. *Medical admission* and *nursing admission* are supported by the *MDMS*. Obtaining consent for processing of patient-related data is supported by the non-computer-based application component for patient data privacy forms. This application component is based on paper forms which are scanned by a clerk (see physical tool layer) and then stored in the *MDMS*.

The *patient administration system*, which is the master application system (Sect. 3.9.1) for the entity type "patient," sends the administrative patient data as a message to the *MDMS*. The *MDMS* can thus store this information about the entity type "patient" in its own database; administrative patient data that is needed to support *medical admission* and *nursing admission* as functions therefore do not have to be reentered in the *MDMS*. The entity type "patient" is both stored in the database systems of the *ERPS* and the *MDMS* what is represented by dashed lines between the domain layer and the logical tool layer in Fig. 2.11.

Both the *patient administration system* and the *MDMS* are run on servers at a virtualized server farm (see relationships between logical and physical tool layer). The application systems can be accessed by different end devices (patient terminal, PC, tablet PC).

Note that Fig. 2.11 shows a model of the information system expressing what the modeler believed to be relevant about the information system. It therefore simplifes some aspects which might be relevant in other contexts.

Another visualization of relationships between 3LGM2 model elements is the matrix view. Figure 2.12 shows connected functions (columns) and application components (lines) expressing that the functions are supported by certain application components. The *patient administration system* supports three different functions, the *MDMS* supports two functions, and one function is supported by the paper-based patient data privacy form system. The matrix view also helps to identify incomplete parts of models. In Fig. 2.12, we can see that there are no functions modeled that are supported by the *fnancial accounting system*, the *human resources management system*, and the *material management system*, which are parts of the *ERPS*.

**Fig. 2.11** 3LGM2 representation of domain layer, logical tool layer, and physical tool layer and their relationships of the function *patient admission* in a hospital

**Fig. 2.12** The matrix visualizes the relations between functions and application components

The matrix view presented in Fig. 2.12 is an alternative representation of confguration lines between functions at the domain layer and application components at the logical tool layer (compare Fig. 2.11). Matrix views are also available for visualizing relations between other pairs of connected 3LGM2 classes.

## **2.16 Exercises**

## *2.16.1 Data, Information, and Knowledge*

Imagine that a physician is given the following information about his patient, Mr. Russo: "Diagnosis: hypertension. Last blood pressure measurement: 160/100 mmHg." Use this example to discuss the difference between "data," "information," and "knowledge"!

## *2.16.2 Systems and Subsystems*

Look up some information on the nervous system of the human body. Then try to identify subsystems of the nervous system. In the same way, can you also describe subsystems of the system "hospital"?

## *2.16.3 Information Logistics*

Imagine a situation in which a physician speaks with Mr. Russo at the patient's bedside. The physician looks up Mr. Russo's recent blood pressure measurement and ongoing medication, decides to increase the level of one medication, and explains this to Mr. Russo. Use this example to discuss the meaning of "information and knowledge logistics." What in this example indicates the right information, the right place, the right people, the right form, and the right decision? What could happen if an information system does not support high-quality information and knowledge logistics?

#### *2.16.4 3LGM2 Metamodel*

Look at the 3LGM22 example in Sect. 2.15. Use this example to explain the meaning of the following elements: functions, entity types, application systems, noncomputer-based application components, physical data processing system, and inter-layer relationships.

#### *2.16.5 Interpreting 3LGM2 Models*

Look at the 3LGM2 sample model in Sect. 2.15 and try to answer the following questions.


## **References**


**Open Access** This chapter is licensed under the terms of the Creative Commons Attribution 4.0 International License (http://creativecommons.org/licenses/by/4.0/), which permits use, sharing, adaptation, distribution and reproduction in any medium or format, as long as you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons license and indicate if changes were made.

The images or other third party material in this chapter are included in the chapter's Creative Commons license, unless indicated otherwise in a credit line to the material. If material is not included in the chapter's Creative Commons license and your intended use is not permitted by statutory regulation or exceeds the permitted use, you will need to obtain permission directly from the copyright holder.

# **Chapter 3 Technological Perspective: Architecture, Integration, and Standards**

## **3.1 Introduction**

From the previous chapter, we already know that a health information system is the socio-technical subsystem of a health care setting which comprises all data, information, and knowledge processing as well as the associated human and technical actors in their respective data, information, and knowledge processing roles. In this chapter, we frst look at what these information systems look like, i.e., we take the technological perspective and examine the architecture of information systems. This perspective is then complemented by the management perspective in Chap. 4.

Section 2.11 taught us that health information systems are constructs built from a variety of components. We will go through the three layers of information systems: the domain layer, the logical tool layer, and the physical tool layer. For each layer, we will explain, step by step, the layer's components and how they are to be assembled and integrated to achieve what users experience as the health information system. Although we keep the non-computer-based part in mind, we will focus on the computer-based part.

In Sect. 3.2, we start at the domain layer and discuss the kind of data that must be processed in health care settings before, in Sect. 3.3, we present the functions interpreting or updating these data. From Sect. 3.4, we describe the tools for data, information, and knowledge processing to be used in health care settings. Starting at the logical tool layer and its application components, we explain how interoperable application components can be integrated, i.e., connected to work together seamlessly (Fig. 3.1) and how various approaches for integration lead to different architectural styles. At Sect. 3.10, we start describing tools at the physical tool layer. Again, we are dealing with integration. But we must be aware that at the physical tool layer, physical data processing systems and the challenges of integration are different from those at the logical tool layer.

In this chapter, we will explain the more generic technological concepts for health information systems which, in principle, are valid for most life situations and

**Fig. 3.1** Health information systems constitute an essential part of providing good health care. Decisions are made by an interdisciplinary tumor board. (Courtesy of Karin Kaiser/MHH)

health care settings. However, in certain situations and settings, there are specifc challenges and requirements leading to specifc architectures for the respective health information systems. In Chap. 6, we will therefore discuss how information systems for certain life situations and in certain settings actually take up these challenges and fulfll these requirements.

After reading this chapter, you should be able to


For you as a reader, achieving these learning objectives is the prerequisite for being able to construct health information systems that are appropriate to people's life situations and that meet the stakeholders' needs. However, you must be aware that these information systems will only be useful to people if they are systematically managed from the start and if their quality is systematically monitored. We will take a closer look at these aspects later on in Chaps. 4 and 5.

Please note that the terms highlighted in italics are terms from the glossary or represent functions or application system types (Sects. 3.3 and 3.4).

## **3.2 Domain Layer: Data to be Processed and Provided**

We will now look at data that represent information and knowledge in both the health care sector and biomedical research. We need to be aware that data is not only stored and processed in one particular information system, but that it often also needs to be provided to or shared with the information system of another facility or setting. For example, data from health care should be provided for research so that medical progress is possible. And data from research should be provided for use in health care to apply new knowledge. This mutual relationship is often described with the concept of the "learning health care system," in which data from everyday medical care is used to gain new insights in medical research and the research results are constantly fed back into practical care (translation) and medical education.

We can distinguish data according to different aspects:


These distinctions are useful because


After this section, you will understand what kinds of data are processed in and provided by most of the health care settings and in biomedical research.

## *3.2.1 Personal vs. Non-personal Data*

According to the European General Data Protection Regulation (GDPR) "... 'personal data' means any information relating to an identifed or identifable natural person" [1]. Data on health and illness are mostly created as personal data. For example, a 12-lead electrocardiogram (ECG), data on physical/mental well-being and weight, the results of an echocardiography, or the activity data for a particular

person like Mr. Russo (Sect. 1.4) are personal data. Individuals' health data belong to the most sensitive personal data on humans.

By cumulating data, the relation to a single identifable person can be reduced. Whether this really turns personal data into non-personal data, however, depends on the information represented. Look, for example, at the German city of Leipzig with around 500,000 inhabitants. Data describing that there are 50,000 people with elevated body temperature in Leipzig in December would certainly not be personal data. On the other hand, if there is a certain rare disease occurring only once among 1,000,000 people, and there is a record with data on a citizen of Leipzig suffering from this rare disease, then this is personal data, even if the data do not include a name, birthday, or other identifer. This is similarly true for human genetic data. Since the genetic code is individual for each person, such data must always be considered personal data.

Personal health data must only be accessible to those persons the individual has authorized before. A health information system must guarantee this requirement of personal data privacy. Likewise, the health information system must ensure data security and data safety of personal health data. While data security ensures availability, confdentiality, integrity, and protection from unauthorized access, data safety concerns protecting personal data against loss.

Personal data on certain persons may only be processed by other persons or facilities if the person expressly consents to having their data processed. If the data are to be processed for another purpose at a later time, the person must give their consent again. In medicine, for example, this means that health data collected from a patient during treatment at a particular health care facility may only be transferred to another health care or research facility with the patient's consent. Thus, Mr. Russo must also frst give his explicit and informed consent for his data to be used in the scientifc study to investigate the effect of close-knit home monitoring on rehospitalization in patients with heart failure. This also applies to pseudonymized health data, i.e., data in which the directly identifying data on the person, for example, the name or a patient number, have been replaced by a number that cannot be directly assigned to a person.

National legislation may allow for different levels of consent. For example, it may be a requirement that individuals must give permission for their data to be used individually for each research project. However, it may also be possible for individuals to give permission for the use of their data for a broader research topic or for research in general (often called "broad consent"). It is important, therefore, to know exactly what options are available in your country.

The handling of personal data in the European Union is comprehensively regulated by the GDPR [1].

Not only personal data but also the processing of non-personal data may be subject to restrictions. For example, if the data are research data obtained by a scientist in the course of experiments at great expense, then this scientist has intellectual property (IP) rights. Such data may only be used if this scientist agrees to its use.

## *3.2.2 Standardized vs. Non-standardized Data*

When a physician, for example Mr. Russo's cardiologist, documents the medical treatment, the data used to describe the treatment, for example in the discharge letter, may be recorded as continuous narrative text without further structuring. We refer to such free text as non-standardized data. With free text, a situation can be described in detail and exactly using full linguistic expressiveness—if there is enough time. The disadvantage of such non-standardized data is, however, that the recorded data are hardly comparable, their completeness cannot be checked, and further processing, especially interpreting its semantics by a machine, is very diffcult. However, there are promising approaches from artifcial intelligence to use natural language processing (NLP) to tag free texts with terminologies (e.g., Systematized Nomenclature of Medicine Clinical Terms (SNOMED CT)) in such a way that further processing is possible. For example, the SNOMED CT code 414024009 may be used to tag the discharge letter describing Mr. Russo's coronary artery disorder. The other two problems, however, cannot be solved with this approach.

If, prior to documentation, the entity types for which data are to be recorded, the properties (attributes) of the objects of these entity types that are to be documented, and the exact value set of these attributes are defned, then we speak of a *standardized documentation* or of standardized data (example in Fig. 3.2). In the case of standardized documentation, it is easy to see—and to validate by a machine whether all the desired data have been captured and the data from different sources can be easily compared. Further processing by machine is also well-prepared. To support standardized documentation, certain terminologies exist and can be used. Depending on the purpose of the documentation, these may be terminologies such as the SNOMED CT mentioned above or classifcations such as the International

#### **Shoulder pain and Disability Index (SPADI)**

#### **Pain scale**

#### **How severe is your pain?**

Circle the number that best describes your pain where: 0 = no pain and 10 = the worst pain imaginable.


**Fig. 3.2** Excerpt from the English version of the Shoulder Pain and Disability Index; a standardized questionnaire for assessing shoulder function [2]

Classifcation of Diseases (ICD) or the nursing diagnosis classifcation of the North American Nursing Diagnosis Association (NANDA) International. NANDA may be used to assign the aforementioned case of Mr. Russo to the class 00146, for example, as Mr. Russo still suffers considerable anxiety from his heart problems. Thus, cases assigned to certain classes can be counted and statistically analyzed.

As standardized data, in contrast to free text data, have a certain structure, they are often also called structured data. Accordingly, free text is often referred to as unstructured data.

## *3.2.3 Entity Types*

In health information systems, data on the following entity types are particularly important:


In the previous two sections, we saw the difference between personal and nonpersonal data and between standardized and non-standardized data. Please note that a lot of data describing individuals are personal data. However, this is not always true. For example, diagnoses without reference to a specifc person are non-personal. There are also differences in terms of standardization for data describing individuals. For example, fndings can be standardized or non-standardized.

#### **3.2.3.1 Entity Types About Individuals**

The following entity types describe individuals. They are listed in alphabetical order.


In health information systems, it is crucial to be able to identify persons unambiguously in order to avoid mix-ups. Each person must be assigned a unique patient identifcation number (PIN). This PIN should be valid and unchangeable for a lifetime (i.e., the PIN should not be based on changeable personal attributes such as the name). The PIN is the main prerequisite for being able to merge all of a person's health-related information. Before a PIN can be assigned, the person must be correctly identifed (3.3.2.1).

#### **3.2.3.2 Entity Types About Patients' Diseases and Their Treatment**

If persons are ill and are the subject of care, we call them patients. Certain data on fndings and about diseases of the patients and their therapies is required for health care.



## **3.2.3.3 Entity Types About Managing Health Care**

Health care takes place at different places. Further data is needed to organize this care.



#### **3.2.3.4 Entity Types About Knowledge**

It is not only information about patients that health care professionals need for care. Medical and nursing knowledge is also required.



## **3.3 Domain Layer: Functions to Be Supported**

In the last section, we introduced the data typical for health care settings and described data by entity types. Now we will explain where and in what contexts data on these entity types are processed in health care settings. As explained in Sect. 2.8, we use information-processing functions—or short: functions—to group classes of information-processing activities.

You will remember that functions use input data on certain entity types. The used data is updated, which often results in data on other entity types. In this section, we will present a selection of functions typical for health care settings and will explain which entity types are used and which are updated. However, we will not (yet) consider how they are typically supported by different data, information, and knowledge processing tools. This will be done in Sect. 3.4 and the following sections.

In this section, you will learn about the most important functions to be performed by patients, informal caregivers, health care professionals, and management and administrative staff in health care settings. You will also learn about data that are used or updated by these functions.

To illustrate which entity types a particular function uses and which it updates, we will use diagrams corresponding to those we also used in Sect. 2.14.1. Please read there again what the symbols mean.

## *3.3.1 Functions to Be Performed by Patients and Informal Caregivers*

In Sect. 1.2, we looked at the life situations in which people have to deal with health. Initially, such life situations take place in the home setting and require specifc action by the individuals and patients concerned. Thus, in our example from Sect. 1.4, Mrs. And Mr. Russo have to cope with their lives despite Mrs. Russo having broken her leg in the bathroom and Mr. Russo having a heart condition. To do so, they must contact with their general practitioner (GP) and with specialists to obtain various information. Their daughters must also participate in the care of their parents. In this context, the daughters are called informal caregivers, just like other relatives or friends who participate in the care of the Russos. In Sects. 1.3.1 and 1.3.3, we had already noted what patients and informal caregivers are particularly concerned about in this context.

In this section, we will now describe the information-processing tasks that patients and informal caregivers have to perform and what entity types are needed. Even though we introduced the term "function" in Sect. 2.8 in the context of health care professionals, it is very well-suited to also describe the information-processing tasks of non-professionals. The corresponding functions include but are not limited to (Fig. 3.4):


#### **3.3.1.1 Medical Knowledge Management by Non-professionals**

Patients and informal caregivers need medical and nursing knowledge, for example, about specifc health conditions and their treatment, about diseases, symptoms, side effects, and about healthy lifestyles and health risks. *Medical knowledge management* by non-professionals as an information-processing function includes gathering such knowledge by consulting health care professionals as well as peers such as fellow patients, relatives, and friends (Fig. 3.3). The corresponding knowledge is gathered in the form of brochures, information material on various media, or references to corresponding sources and media. Patients and informal caregivers select units of knowledge and references to knowledge which they consider helpful.

**Fig. 3.3** *Medical knowledge management* by non-professionals (for the legend refer to Sect. 2.14.1)

As a result of *medical knowledge management*, patients and informal caregivers will have selected personal knowledge at hand–or in their mind. They must then organize this knowledge according to its perceived importance and relevance.

#### **3.3.1.2 Self-Diagnostics**

Individuals who feel ill or who are living a health-conscious lifestyle will carefully monitor and assess their own health conditions or the conditions of household members. By using the resulting self-gathered symptoms and acquired personal medical and nursing knowledge, they may try to identify their disease. This function, *selfdiagnostics*, results in a self-diagnosis, which later may lead to *self-treatment*. This is illustrated in Fig. 3.4.

For monitoring, individuals may use health diaries and personal digital devices, for example, smartphone applications that may provide automatic monitoring of symptoms and conditions.

#### **3.3.1.3 Self-Treatment**

*Self-treatment* usually means treating one's own disease without direct medical supervision or intervention and relies on selected personal knowledge. We use this term here to indicate patient actions to treat their disease by themselves, for example, at home. Such *self-treatment* may be based on self-diagnoses or on diagnoses resulting from the execution of diagnostic procedures by health care professionals and flling the respective orders.

*Self-treatment* includes physical exercise, managing prescribed medication and self-medication, and using digital health applications (DiGAs) to support mental health, for example.

*Self-treatment* may also include *prevention*, which is better than cure. Many diseases result from unhealthy lifestyles and behavior. A change in behavior can therefore both prevent and, in many cases, make a signifcant contribution to curing

**Fig. 3.4** Summary of functions to be performed by patients and informal caregivers (for the legend refer to Sect. 2.14.1)

diseases. *Prevention* through healthy behavior is an important contribution to one's own health, which can be done very well in one's own responsibility, especially in the home environment. *Prevention* includes using guidelines, reporting outcomes in diaries, and organizing appointments for training and advice as well as for transport to or from a health care facility providing support.

#### **3.3.1.4 Arrange Appointments**

Either because of a self-made diagnosis or on the basis of a physician's diagnosis and order, it may become necessary to visit a certain health care facility. This could be, for example, an initial consultation with the family physician, a referral to the radiologist for a radiological examination, or a visit to a physiotherapist. In any case, it is usually necessary to arrange an appointment beforehand. This can be very demanding for the patient if several facilities have to be contacted in order to obtain a timely appointment. Patients may use phones, physicians' websites, or even specialized apps for this function.

#### **3.3.1.5 Filling Physician's Orders**

A visit to a physician usually involves the physician recommending that the patient take certain measures. For example, they may propose that the patient see a specialist, receive a specifc physiotherapeutic treatment, take a set of medicines in a specifc order, or take preventive measures by changing unhealthy behavior. It is often a challenge for the patient to both remember these orders and organize their implementation. Compliance with the measures prescribed or recommended by a physician or therapist is referred to as adherence.

## *3.3.2 Functions to Be Performed by Health care Professionals and Other Staff in Health care Facilities*

#### **3.3.2.1 Patient Care**

*Patient care* in a facility begins with the patients' admission and ends with their discharge and any necessary transfer to another facility. During the patients' stay at the facility, decisions must be made about the diagnostics and therapy to be executed, and appropriate procedures must be ordered. The data generated during treatment must be coded so that it can be further processed.

#### Patient Admission

The prerequisite for the treatment of a sick person by a health care professional in a health care facility is the admission of the person to that facility. *Patient admission* (short: admission) aims at recording and distributing the patient demographic and insurance data as well as data on the medical and nursing history (Sect. 3.2.3.2). In addition, each patient must be identifed correctly and a unique patient and *case identifcation number* (CIN) must be assigned.

This function can be decomposed as follows (Fig. 2.4 in Sect. 2.14.1):

#### *Appointment Scheduling*

The health care facility must schedule an appointment for the patient's visit. Appointments must also be made in connection with *order entry* for diagnostic services in a radiology department, for example.

In addition, unplanned *patient admissions* must be possible (e.g., in case of emergencies).

#### *Patient Identifcation*

Before health care professionals treat a patient, they must be sure exactly who the person they are treating is. Patients will normally identify themselves or with the assistance of relatives through a health insurance card or identity card. Based on such documents, the health care professional or administrative staff of the respective health care facility assigns a unique PIN to the patient. A new PIN is assigned only if the patient is in the facility for the first time. If patients have already been in the facility, they must be identified as recurrent, and previously documented information must be made available (such as previous diagnoses and therapies). Hospitals, in particular, must be able to distinguish a patient's different cases or hospital stays. Therefore, in addition to the PIN, a *case identification number (CIN)* is usually assigned as part of *administrative admission*.

Merging all health-related data and documents of a particular patient can only succeed if all health care professionals and all health care facilities caring for the patient use the same PIN. If each facility assigns its own PIN to a patient, a tool is needed to map the different PINs of one patient to each other. Such an application system is called a *master patient index (MPI)* and will be discussed in Sect. 3.4.1. Some countries provide a single unique PIN for every citizen, for example, on the health insurance card.

*Patient identifcation* as a function therefore interprets the entity type "patient" by considering, for example, their name, birthday, and data from the ID card and updates the same entity type by updating the PIN.

#### *Administrative Admission*

*Administrative admission* starts following *patient identifcation*. It creates the socalled case, being the aggregation of several contacts clustered according to specifc clinical and/or organizational purposes of the facility. In case of inpatient treatment, a case summarizes the stay at the facility from *patient admission* until discharge. Each case is uniquely identifed by its CIN. Important administrative data, such as insurance data or details about booked services, patient's relatives, admitting physician, and transfer diagnoses, must be recorded. The patient is assigned to a certain area, for example, a ward and a bed. Some of the administrative data must be available to other functions through the help of certain organizational media (such as adhesive labels and smart cards). Administrative data form the backbone of information processing in a health care facility. In case of changes, patient data must be maintained and communicated. If the referring physician, for example, the GP, has communicated relevant information (e.g., previous laboratory fndings), this information must be sent to the responsible physician in the admitting facility. In hospitals, *administrative admission* is usually done either in a central patient admission area by administrative staff or directly on the ward (e.g., during emergencies or on the weekend) by health care professionals. In medical offces, there is usually a reception desk where this function is performed.

Even in emergencies, *patient admission* is necessary. At the very least, *patient identifcation* must be performed in order to assign a proper PIN and CIN. In emergencies, a short version of *administrative admission* may be applicable. If the patient is unconscious and does not have an identity card, a dummy name may be recorded to provide PIN and CIN. If using PIN and CIN properly, there will be no problem to replace the dummy name by the correct name later on.

#### *Medical Admission*

At the frst contact with the patient, the physician will carry out the *medical admission*. This typically comprises recording the patients' medical history (disease history, systems review, social history, past medical history, family history, medication). Some of this information may be collected from documents of the referring physician which are taken to the facility by the patients themselves.

As a result of *medical admission*, the admission diagnosis must be stated and coded using the mandatory classifcation, for example, ICD-11.

The medical history must be made available for other functions by including it with the patient's health record. However, some facilities only have access to patient-related documents and data that originated from the same facility, i.e., the facility's patient record.

#### *Nursing Admission*

Especially in the case of inpatient treatment in a hospital, nursing home, or rehabilitation center, the nurse in charge will proceed with the *nursing admission* at the ward. This typically comprises introducing the patient to the ward and recording the nursing history. Administrative data and the reason for hospitalization are already at the nurse's disposal. The nursing history contains information about the current diagnosis and therapy, orientation, communication ability, social contacts, nutrition, mobility, personal hygiene, and vital signs. Computer-based or department-specifc, (semi-) standardized data entry forms may be available to collect the data. The collected data must be made available for the whole stay by including it in the patient's health record.

#### *Visitor and Information Service*

In any health care facility that provides inpatient care, administration must have a good overview of the recent bed occupation, i.e., about the patients' stay at the hospital. This is, for example, important for the clerks at the information desk, who must be able to inform relatives and visitors correctly, as well as for some general administration statistics.

#### *Decision-Making, Planning, and Organization of Patient Treatment*

The treatment of the patient requires the execution of a variety of diagnostic and therapeutic procedures. Health care professionals must decide with the patient which procedures to execute based on available data and knowledge. Then these procedures must be carefully planned and initiated. This process is repeated each time new information and knowledge is available.

This function can be decomposed as follows (Fig. 3.5):

#### *Decision-Making and Patient Information*

Health care professionals must decide on the next steps to take, for example, certain diagnostic or therapeutic procedures. Depending on the complexity of a diagnostic or therapeutic decision, they should be able to consult internal or external experts

**Fig. 3.5** Function *decision-making, planning, and organization of patient treatment*, its subfunctions and interpreted and updated entity types (for the legend refer to Sect. 2.14.1)

(e.g., in specialized hospitals) to obtain a second opinion. In this context, (tele)conferences may help. Health care professionals must be able to access all relevant patient data specifc to a situation in addition to general medical and nursing knowledge (e.g., guidelines, recent study results and standards). Medication prescription may be supported by providing knowledge about adverse drug events. Decisions about clinical procedures must be documented. Patients must be involved in the decision-making process, the consequences of the planned diagnostic or therapeutic procedures should be explained, and their informed consent must be documented. Decision-making is a permanent function that is triggered by new information about the patient and the availability of new knowledge.

#### *Medical and Nursing Care Planning*

The next steps must be planned in detail. For each medical procedure (such as a radiological examination, an operation, or a chemotherapeutic treatment) as well as for each nursing procedure, the type, extent, duration, and responsible person and facility have to be determined. In nursing, care planning is documented in nursing care plans containing nursing problems, nursing goals, and planned nursing procedures. If necessary, other health care professionals are ordered to execute the planned procedures (e.g., a physician's medical bandaging orders to be executed by a nurse or home care service at the patients' home).

Care planning in cancer treatment is often performed by tumor board reviews. This means that a number of physicians who are experts in different specialties (disciplines) review and discuss the patient's medical condition and treatment options.

#### Order Entry

Diagnostic and therapeutic procedures must often be ordered at specialized service units (e.g., laboratory, radiology, or pathology). These units may be an internal part of the health care facility of the treating health care professional or may be an external institution. The units execute the ordered procedures and communicate the fndings or results back to the ordering facility. In order to avoid mix-ups, all units and facilities involved must use the same PIN. This is especially challenging when the service units do not belong to the same facility.

This function can be decomposed as follows (Fig. 3.6):

#### *Preparation of an Order*

If the order is to examine the patient's tissue or fuid samples, the specimen must be unambiguously assigned to a patient and then submitted (e.g., blood sample). Depending on the available service spectrum offered by a service unit, which may be presented in the form of service catalogs, the health care professional selects the appropriate service on an order entry form. Patient identifcation data (name, PIN) are documented together with relevant information such as recent diagnoses, relevant questions, service ordered (e.g., lab test), and other comments (e.g., on special risks).

If a medication is ordered by a physician and computer-based tools for *order entry* are used, computerized decision support systems could alert the physician, for example, in case of medication errors when a medication is ordered to which the patient is allergic.

The order may only be initiated by authorized persons. The order must be transmitted quickly and correctly to the service unit or to the person who is to execute the

**Fig. 3.6** Function "order entry," its subfunctions and interpreted and updated entity types (for the legend refer to Sect. 2.14.1)

order. If a specimen is transferred, it must be guaranteed that the order and the specimen can be linked to each other at the service unit. It should be possible for the ordering health care professional to modify orders that have already been transferred, if necessary.

#### *Appointment Scheduling*

The patient's appointments must be scheduled (e.g., in radiological units) depending on the type of order. During scheduling, the demands of all parties (e.g., ordering physician, service unit, patient, transport unit, public transport) must be fairly balanced. This can be particularly challenging in the context of outpatient care if, for example, a suitable radiologist must frst be found near the patient's place of residence and possible examination dates must be determined. It can also be complicated to have the patient transported to the radiologist. Depending on the health care system, patients may have to handle these tasks themselves and it becomes their function (Sect. 3.3.1).

#### Execution of Diagnostic, Therapeutic, and Nursing Procedures

The planned diagnostic, therapeutic, or nursing procedures (such as operations, radiotherapy, radiological examinations, medication) must be executed. Adequate tools and resources (e.g., staff, room, equipment) for the execution of the necessary procedures have to be available. This must be managed according to the special needs of the respective facility and health care setting (Chap. 6).

It is important that changes in care planning that may be due to new fndings are promptly communicated to all involved units, facilities, and persons, enabling them to adapt to the new situation. All clinically relevant patient data (such as vital signs, orders, results, decisions) must be recorded as completely, correctly, and quickly as necessary. This supports the coordination of patient treatment among all persons and facilities involved and provides the legal justifcation for the actions taken. In inpatient care, a lot of these data may be recorded, for example, on the ward. In outpatient care, however, with the health care professionals caring for the patient at home, much of the data must also be collected and documented at the patient's home.

As far as possible and whenever sensible, data and metadata should be recorded and represented in a standardized manner (compare 3.2.2) to allow for seamless care across providers, for data aggregation and statistics, for computerized decision support, and for data retrieval. It is important that data can be linked by PIN and CIN even when data originate from different areas (such as ward, service unit, outpatient unit, home). The health care professionals and their facility must usually fulfll a lot of different legal reporting (such as for epidemiological registers) and documentation requirements. The items to be documented depend partly on the documenting unit and the documenting health care professional group (such as documentation by physicians or nurses, in outpatient units, in operation rooms, or in patients' homes). Clinical information should also be available for other functions such as *fnancial accounting*, *controlling*, or *quality management*.

This function can be decomposed as follows (Fig. 3.7):

**Fig. 3.7** Function *execution of diagnostic, therapeutic, and nursing procedures*, its subfunctions and interpreted and updated entity types (for the legend refer to Sect. 2.14.1)

#### *Execution of Diagnostic and Therapeutic Procedures*

The planned diagnostic and therapeutic procedures must be executed. All procedures must be documented. Findings and reports must be transmitted (as quickly as necessary) back to the ordering unit and presented to the responsible health care professional. They must be unambiguously assigned to the correct patient. The responsible physician should be informed about new results, and critical fndings should be highlighted.

The function *execution of diagnostic and therapeutic procedures* can be specialized to:


#### *Execution of Nursing Procedures*

The planned nursing procedures (concerning medication, excretion, decubitus, hair and nail care, skin care, wound treatment, body washing, oral and dental care, nutrition and liquid balance, thrombosis) are executed. All *patient care*

procedures, their impact on the patient's health status, and changes to the care plan must be documented. The responsible physician must be informed of any facts relevant to the therapy.

#### Coding of Diagnoses and Procedures

The health care facility must be able to document and code all stated diagnoses and all executed medical procedures in a correct, complete, quick, and patient-oriented way. These data form the basis for billing, for reports, and for research. Diagnoses and medical procedures are also used for *controlling*. In addition, legal requirements stipulate that some of the data must be documented and communicated. This data is also important for medical research.

Diagnoses and medical procedures are recorded and coded in a standardized way (e.g., using the ICD11 for diagnoses codes [4]) and then processed. Diagnoses and medical procedures are at least partly derivable from clinical documentation. To support their documentation, adequate coding catalogs must be offered and maintained. Tools are needed that help health care professionals to quickly fnd the correct codes for the diagnoses and medical procedures.

The function *coding of diagnoses and procedures*, its decomposition in subfunctions, and the entity types to be interpreted and updated are summarized in Fig. 3.8.

**Fig. 3.8** Function *coding of diagnoses and procedures*, its subfunctions and interpreted and updated entity types (for the legend refer to Sect. 2.14.1)

**Fig. 3.9** Function *patient discharge and transfer to other facilities*, its subfunctions and interpreted and updated entity types (for the legend refer to Sect. 2.14.1)

Patient Discharge and Transfer to Other Facilities

In case of inpatient care in a health care facility after the patient's care has been completed, the patient is discharged and sometimes referred to other facilities (e.g., GPs or rehabilitation centers). *Patient discharge and transfer to other facilities* (short: discharge) covers *administrative, medical, and nursing discharge*.

This function can be decomposed as follows (Fig. 3.9):

#### *Administrative Discharge and Billing*

The process of administrative patient discharge initiates fnal billing and the fulfllment of legal reporting requirements (e.g., statistics on diagnoses and procedures). In recent years, diagnosis-related group (DRG) systems have been introduced for patient billing in most countries. That means that bills for patient treatment are no longer calculated based on daily rates but on the DRG in which a patient case was classifed. Diagnoses, procedures, patient's age, and other criteria serve as an input for the calculation of a DRG.

#### *Medical Discharge and Medical Discharge Summary Writing*

*Medical discharge* entails the completion of the documentation and the writing of a discharge summary by the attending physician. The discharge summary includes the relevant diagnoses, important fndings, therapeutic procedures, current patient state, and recommendations for further treatment. The hospital must be able to transmit this and other information (e.g., radiological images) to other facilities as quickly as possible. To speed up this process, a short report (i.e., physician's discharge letter) is often immediately communicated to the next facility containing, for example, the diagnoses and therapeutic treatments. It is then later followed by a more detailed report.

#### *Nursing Discharge and Nursing Discharge Summary Writing*

*Nursing discharge* entails the completion of the documentation and the writing of a nursing discharge summary by the attending nurse. The nursing discharge summary comprises, for example, information about activity level, diet, and wound care.

#### **3.3.2.2 Supply and Disposal Management, Scheduling, and Resource Allocation**

The health care facility must offer suffcient and well-organized resources for *patient care*. This is true for wards (ward management), outpatient units (outpatient management), and service units (department management). Effcient process organization is extremely important, for example, in outpatient units or service units, and can be supported, for example, by providing working lists for individual staff members by issuing reminders about appointments or by visualizing actual process fow. The facility's information system must be able to support communication between all persons involved in *patient care*. This comprises synchronous (e.g., telephone) and asynchronous (e.g., blackboards, brochures, email) communication. Staff members must be able to be contacted within a prescribed period of time.

Supply and Disposal Management

Supply and disposal of materials, food, drugs, and so on must be guaranteed. All of a facility's departments should be able to order from up-to-date catalogs. The corresponding service units (stock, pharmacy, and kitchen) must be able to deliver correctly and on time.

*Supply and disposal management* can be decomposed as follows (Fig. 3.10):

• *Catering*

According to their health status, patients have different nutritional needs. It must be ensured that the patients are provided with the right dietary food at the right time.

• *Material and medication management*

Nurses and physicians must be able to anticipate shortages of material such as medical strips, bandages, or needles to order new material from a central supplier in time.

**Fig. 3.10** Function *supply and disposal management*, its subfunctions and interpreted and updated entity types (for the legend refer to Sect. 2.14.1)

• *Laundry management*

The hospital must permanently be supplied with linen, towels, sterile scrubs, surgical masks, etc.

• *Management of medical devices*

In addition to other resources, medical devices must be registered and maintained according to legislation. Due maintenance must be organized, documented, and completed.

#### Scheduling and Resource Allocation

Various resources are needed for *patient care* in health care facilities. The function *scheduling and resource allocation* comprises staff planning, bed planning, room planning, and device planning. All resource planning activities must be coordinated. When procedures are scheduled, the demands of both the service unit and the ordering unit with regard to scheduling the appointment must be considered. Request, reservation, confrmation, notifcation, postponement, and cancellation must be supported. All involved staff members and patients should be informed about the appointments. Postponements and cancellations should be communicated to all involved persons in time.

This function can be decomposed into the functions *appointment scheduling*, *scheduling and resource planning with the medical service unit,* and *scheduling and resource planning with the patient transport service* (Fig. 3.11). *Appointment scheduling* was also listed as a subfunction of *patient admission*.

**Fig. 3.11** Function *scheduling and resource allocation*, its subfunctions and interpreted and updated entity types (for the legend refer to Sect. 2.14.1)

**Fig. 3.12** Function *human resources management*, its subfunctions and interpreted and updated entity types (for the legend refer to Sect. 2.14.1)

#### Human Resources Management

This contains all tasks for the development and improvement of the productivity of staff. It comprises, for example, staff and position planning, the staff register, staff scheduling, and staff payroll.

This function can be decomposed as follows (Fig. 3.12):


#### **3.3.2.3 Administration of Health care Facilities**

*Administration of health care facilities* supports the organization of *patient care* and guarantees the fnancial survival and the economic success of the hospital. Subfunctions are:

Patient Administration

Patient administration comprises the administrative tasks in a health care facility dealing more or less immediately with patients. Thus, it is an aggregation of the subfunctions


#### Archiving of Patient Information

Relevant data and documents containing patient information must be created, gathered, presented, and stored in such a way that they are effciently retrievable during the whole process of patient treatment. These data and documents are primarily stored in patient records. A mixture of paper-based and computer-based patient records is still used today. Certain legal requirements usually must be considered.

This function can be decomposed as follows (Fig. 3.14):

• *Opening of a patient record*

*Administrative admission* triggers the *opening of a patient record*. The patient record may be electronic or paper-based or a mixture of both. Standards for document fling formats must be established and used.

• *Administration and allocation of patient records*

A paper-based archive must be able to manage patient records and make them available upon request within a defned time frame. The exact location of each record should be known (e.g., in which archive, on which shelf). Robot systems may store and gather paper-based records automatically. Lending and return of records (e.g., for patients coming for multiple visits) must be organized, while respecting different access rights that depend on the role of the health care professionals in the process of *patient care*.

**Fig. 3.13** Function *patient administration*, its subfunctions and interpreted and updated entity types (for the legend refer to Sect. 2.14.1)

**Fig. 3.14** Function *archiving of patient information*, its subfunctions and interpreted and updated entity types (for the legend refer to Sect. 2.14.1)

• *Long-term archiving*

After discharge of the patient, patient records must be archived for a long time (e.g., for 10 or 30 years, depending on the legal regulations). The archive must offer enough space to allow the long-term storage of patient records. Their authenticity and correctness can be proven more easily, for example in case of legal action, if they are archived in accordance with legal regulations.

#### Quality Management

*Quality management* comprises all activities of a health care facility's administration to assure and continuously improve the quality of *patient care*. This includes setting goals, defning responsibilities, and establishing and monitoring the processes to realize these goals. This covers, for example, internal reporting containing quality indices. *Quality management* requires information about patients and treatments as well as knowledge about diagnostic and therapeutic standards.

This function can be decomposed as follows (Fig. 3.15):

• *Internal quality management*

*Internal quality management* assures a defned quality of all processes and outcomes of the hospital. An internal reporting system, which presents qualityrelated indicators, is also covered. Medical, nursing, and administrative guide-

**Fig. 3.15** Function *quality management*, its subfunctions and interpreted and updated entity types (for the legend refer to Sect. 2.14.1)

78

lines may be defned, stored, and presented. There exists a structured complaint management.

• *Performance of legal notifcation requirements* Legal notifcation requirements for quality assurance must be completed.

Cost Accounting

For controlling purposes, it is necessary to keep track of services, their costs, and who has received the services. *Cost accounting* usually investigates which costs incur (cost-type accounting), where costs incur (cost center accounting), and for what activities or services costs incur (cost unit accounting). According to the accounting purpose, the time period to be observed and the scope of the costs to be accounted have to be defned. The results of *cost accounting*, i.e., key performance indicators (KPI), serve as input for *controlling* (Figs. 3.16 and 3.17).

**Fig. 3.17** Function *controlling*, its subfunctions and interpreted and updated entity types (for the legend refer to Sect. 2.14.1)

#### Controlling

The health care facility must be able to gather and aggregate data on its operation in order to control and optimize it. This covers, for example, *staff controlling*, *process controlling*, *material controlling*, and *fnancial controlling*. In hospitals, for example, the number of patient cases, the length of patients' stays in the hospital, and the case mix index, which is calculated from the patients' DRGs, are KPIs serving as input for controlling reports (Fig. 3.17).

#### Financial Accounting

All the facility's fnancial operations must be systematically recorded to meet legal requirements. *Financial accounting* comprises, for example, *debtor accounting*, *credit accounting*, and *asset accounting*. This type of accounting requires information from bills and creates new values for KPIs (Fig. 3.18). The health care facility must support general statistical analysis, for example, calculation and analysis of economic data.

**Fig. 3.18** Function *fnancial accounting*, its subfunctions and interpreted and updated entity types (for the legend refer to Sect. 2.14.1)

#### Facility Management

The management of buildings, areas, and utilities of the health care facility is usually subsumed by the term *facility management*. As this often also involves high costs, this management area also infuences KPIs (Fig. 3.19).

Management of Information Systems1

*Management of information systems* plans the information system of an enterprise and its architecture, directs its establishment and its operation, and monitors its development and operation with respect to the planned objectives. Different management levels have different perceptions and interests.

<sup>1</sup>Now we have come full circle. Our book deals with information management and especially strategic information management. Since information systems are the subject of information management, and information systems are designed to support all necessary functions of an enterprise, they should support information management as well. For a more thorough explanation of strategic information management, refer to Sect. 4.3.

**Fig. 3.20** Function *management of information systems*, its subfunctions and interpreted and updated entity types (for the legend refer to Sect. 2.14.1)

This function can be decomposed as follows (Fig. 3.20):

• *Strategic management of information systems*

*Strategic management of information systems* deals with the enterprise's information processing as a whole and establishes strategies and principles for the evolution of the information system. An important result of strategic management activities is a *strategic information management plan* that is aligned with the hospital's business strategy. It includes the direction and strategy of information management and the architecture of the enterprise information system.

• *Tactical management of information systems*

*Tactical management of information systems* deals with particular functions or application components that are introduced, removed, or changed. Usually, these activities are done in the form of *projects*. Such tactical information management projects are initiated by *strategic management of information systems*. Thus, *strategic management of information systems* is a vital necessity for *tactical management of information systems*. The result of tactical information management projects is the information system.

• *Operational management of information systems*

*Operational management of information systems* is responsible for operating the components of the information system. It ensures its smooth operation in accordance with the strategic information management plan. Additionally, operational information management plans, directs, and monitors permanent *IT services* for the users of the information system.

**Fig. 3.21** Function *management of health care facilities*, its subfunctions and interpreted and updated entity types (for the legend refer to Sect. 2.14.1)

#### **3.3.2.4 Management of Health care Facilities**

*Management of health care facilities* decides on questions of fundamental importance for the health care facility's development (goals, strategic decisions, personnel decisions and decisions about budget, investments, or key treatments). *Management of health care facilities* must focus on high quality of *patient care*, taking into account economic as well as legal and other requirements. Information needed and produced is shown in Fig. 3.21.

#### **3.3.2.5 Clinical Documentation: A Function?**

It may be surprising that "documentation" is not listed as a function in the previous sections. In fact, clinical documentation, which comprises medical documentation and nursing documentation, is a time-consuming and often unpopular duty of health care professionals. Moreover, every function described so far requires a lot of documentation. The results of diagnostic procedures have to be written down, medical histories have to be documented, and so on. Documentation takes place every time a function is performed, new information is generated, and respective data are stored somehow somewhere. Thus, every introduced function which updates an entity type is a documenting function. In fact, documentation is a part of all functions updating an entity type, even of those performed by patients.

## **3.4 Logical Tool Layer: Types of Application Systems in Health care Facilities**

After having looked at data to be processed and at functions to be performed we now describe tools for data, information, and knowledge processing at the logical tool layer of information systems, i.e., the application components supporting these functions and storing and processing the data.

Health care facilities still have non-computer-based application components and use paper as a physical tool. For example, parts of clinical documentation while performing functions are occasionally still done with paper-based patient records. Thus, despite the growing portion of electronic documents, the "paperless hospital" still seems to be a remote ideal today. There might be a continuing need for some paper-based documents. Typical application components that are still paper-based comprise, for example, the patient chart, the patient record, and clinical text books and knowledge sources.

In spite of this still existing signifcance of non-computer-based information processing in health care, we will focus here on application systems, i.e., the computerbased application components.

In Sect. 3.3.2, we could see that many functions are commonly found in all health care facilities. Although they use different application systems to support the functions, there are typical application systems to support health care professionals in health care facilities. We take a closer look at the respective types in the following subsections. In Sect. 6.8, however, we will look at types of application components to support patients and informal caregivers.

We will sum up the characteristics of the application systems in tables enumerating the supported functions; please refer to Sect. 3.3 for their detailed descriptions. For every function, we also list typical features that the application system should offer. A feature is a functionality offered by the application system's software which directly contributes to the fulfllment of one or more functions (Sect. 2.9).

Please note that we refer to some of the application system types as "XYZ information system" (e.g., *laboratory information system*). Although this sounds contradictory to our defnition of the term "information system," we did so in order to integrate the popular names and hope you will not be confused.

In this section, you will get to know the types of application systems that are used in health care. In later Sects. 3.5–3.9, we will explain step by step how and under which conditions the application systems described here can be assembled, i.e., integrated, in the information system. Finally, in Sect. 3.10, we will discuss the physical data processing systems on which the application systems need to be installed. Finally, in Chap. 6, we will take a closer look at specialized application systems in specifc health care settings.

## *3.4.1 Patient Administration Systems*

Whether hospital, medical offce, or rehabilitation center, a health care facility needs to administer patients. *Patient administration* comprises the functions from Sect. 3.3.2.3.1 as listed in Table 3.1.

Application systems supporting *patient administration* are referred to as *patient administration systems* or sometimes "patient management systems." They must provide correct, complete, and up-to-date administrative patient data for all other application components. In addition, all other application components must be able to transmit relevant administrative patient data (e.g., diagnoses) to the *patient administration system*. Therefore, the *patient administration system* can be regarded as the center of the administrative memory of the facility's information system.


**Table 3.1** Set of functions and related features typically to be supported by *patient administration systems*

During *patient admission*, *patient administration systems* must support the retrieval of patient data (e.g., by name or birthdate) to avoid duplicate and erroneous registration of patients. The resulting identifcation numbers PIN and CIN are of utmost importance for the whole information system. They are the basis for correct assignment of patient-related data to patients and thus are the very precondition for a valid patient record—regardless if it is electronic or not. Without correct PIN and CIN, all the high-tech of a modern information system would be useless.

Application systems providing a correct PIN are often called *MPI*. Hence, a *patient administration system* is an *MPI*. It is essential to have exactly one *MPI* in a health information system—regardless whether it is an institutional health information system where the MPI provides the PIN or a transinstitutional health information system (tHIS) where the MPI provides the transinstitutional PIN and, if necessary, cross-references the institutional PINs.

Both PIN and CIN as well as the related patient information must be made available to other application components of the facility. If the patient already has a paper-based patient record, the application component should automatically trigger the transfer of this record from the patient record archive to the unit the patient has been admitted to.

In addition, *patient administration systems* may update patient information in case of changes or merge patient information from two cases if a new PIN was wrongly assigned to a patient.

*Patient administration systems* are usually not only used by administrative staff but also by nurses and doctors at the ward. In the latter case, they also support daily management activities by health care professionals that occur on a ward. In particular, they support the assignment of patients to beds and rooms with the features shown in Table 3.1.

Some countries have different regulations for inpatient and outpatient billing. Particular features may therefore be needed for billing in outpatient departments and medical offces.

## *3.4.2 Medical Documentation and Management Systems (MDMS)*

In addition to a *patient administration system* to support the management of patients, health care facilities need another application system to support functions related more closely to organizing and documenting patients' diagnostics and treatment. These functions are summarized in Table 3.2.

Application systems designed to especially support the functions in Table 3.2 are called *medical documentation and management systems (MDMS)*. They typically contain specialized modules for different medical felds (e.g., ophthalmology, psychiatry, dermatology) and usually offer generic forms for free text, semi-structured, or structured (e.g., drop-down lists) data entry for medical


**Table 3.2** Set of functions and related features typically to be supported by *medical documentation and management systems*

documentation as well as support for speech recognition, reporting, and analysis features. The more data are structured, the easier patient-related computer-based decision support and statistical data analysis are. It is important that users are able to adapt the features to their needs (e.g., by defning which items have to be documented and which constraints the entered data must meet). When reports are generated, the reuse of already-documented data (e.g., diagnoses, fndings from radiology, or lab) should be supported.

Besides clinical documentation, the *coding of diagnoses and procedures* is very important. Coding components must support the easy search for suitable diagnosis and procedure classes and their respective codes in classifcations for a given medical feld. Alternatively, free text can be analyzed using natural language recognition methods. If these coding components are separate from the *MDMS*, it must be guaranteed that the codes can be transferred to *MDMS*. The *MDMS* should also allow an adequate layout of diverse reports. When several persons are involved in the creation of a report (e.g., discharge summaries may be dictated by a junior physician, written by a secretary, and approved by a senior physician), the application components should support the management and distribution of different versions of a document having different status (e.g., preliminary or approved).

Medical documentation is the basis for decision-making, planning, and organization of patient treatment. The *MDMS* must therefore support the medical staff by providing medical knowledge, which should be preselected using documented data about the patient's conditions. Ideally, a respective "infobutton" [5] should be implemented.

## *3.4.3 Nursing Management and Documentation Systems (NMDS)*

Although patient treatment and *patient care* or nursing are inherently intertwined, these two areas are often considered separately, even in information systems. Corresponding to the areas of responsibility of physicians and nurses, a distinction is also made, for example, between medical informatics and nursing informatics. Unfortunately, this often also results in other application systems being used to support the nursing process, even though doctors and nurses need to work together particularly closely.

The nursing process comprises *nursing admission*, nursing care planning with defnition of problems, formulation of nursing aims, and planning of nursing tasks, then *execution of nursing procedures* and *nursing discharge and nursing discharge summary writing*. Like medical diagnoses and procedures, nursing diagnoses and procedures must be coded. The working hours of nursing staff, who usually work in shifts, must be carefully managed. These functions, together with related features, are listed in Table 3.3.

Application systems designed to especially support the functions in Table 3.3 are referred to as *nursing management and documentation systems (NMDS)* or sometimes "nursing information system."


**Table 3.3** Set of functions and related features typically to be supported by *nursing management and documentation systems*

The *NMDS* must support the documentation of all steps of the nursing process. To support nursing care planning, the defnition and use of predefned nursing care plans (comprising recent problems of the patient, nursing goals, and planned nursing tasks) is helpful.

The *NMDS* offers support for using predefned nursing terminologies and nursing classifcation such as NANDA, NIC, and NOC.2

## *3.4.4 Computerized Provider Order Entry Systems (CPOE)*

The care of patients is a highly collaborative process. Not only are different facilities involved, but many service units as well as different health care professionals with different tasks are also involved within the facilities. The interaction of these units and people is handled by orders that one unit directs to another unit. This is summarized in the function *order entry*. *Order entry* can comprise both ordering of diagnostic or therapeutic procedures and ordering of drugs.

Application systems designed to especially support the function *order entry* and to provide the features in Table 3.4 are referred to as *computerized provider order entry systems (CPOE)* or sometimes *computerized physician order entry systems*. *CPOE systems* support formulation of the order, *appointment scheduling*, printing of labels, and the communication of the order to the service unit.

When ordering drugs, physicians may choose the most appropriate drug or generic drug from drug catalogs. The *CPOE system* may then also offer decision support functionalities such as dosage calculation, drug–drug interaction checks, drug allergy checks, or drug lab checks to prevent prescription errors.

When ordering diagnostic or therapeutic procedures, the results (e.g., lab values or X-ray report) must then be communicated back to the ordering facility. *CPOE systems* offer service catalogs that present the available service types of the different service units (e.g., laboratory, radiology, surgery). Order sets that describe a typical set of combined orders (e.g., a combination of diagnostic procedures that have to be performed in a given situation) can support the ordering process; they are activated and modifed by the ordering clinician. Some *CPOE systems* support receiving and presenting fndings. However, this is usually done by other application components such as the *radiology information system (RIS)* or *laboratory information system (LIS)*.

<sup>2</sup>NANDA = North American Nursing Diagnosis Association (the abbreviation is often used synonymously for the international classifcation of nursing diagnoses), NIC=Nursing Interventions Classifcation, NOC=Nursing Outcomes Classifcation.


**Table 3.4** Set of functions and related features typically to be supported by *computerized provider order entry systems*

## *3.4.5 Radiology Information Systems (RIS)*

Facilities that handle the *execution of radiological examinations* exist as departments of hospitals, for example. There, they execute radiological examinations primarily on the inpatients of the respective hospital. Such facilities may also be legally and economically independent facilities, however, which then typically serve the care of outpatients, for example, from medical offces.

When radiological examinations are needed, wards or medical offces order them and schedule an appointment. In the case of outpatient care, however, the patients often have to perform the function *arrange appointments* themselves. The examinations may then be done using imaging devices, for example for computed tomography, magnetic resonance imaging, ultrasonography, or digital radiography. The imaging devices are called modalities. Based on the generated images, a specialist in radiology creates a report, which is then sent and presented (often together with selected pictures) to the ordering physician. The related functions are summarized in Table 3.5.Application systems designed to especially support the functions and to provide the features shown in Table 3.5 are usually called *radiology information systems (RIS)*. Please note that according to our defnition, these application systems are not information systems, even if the name suggests that they are.

The *RIS* offers some features which are also provided by the *patient administration system* (3.4.1), i.e., features for registering patients, *appointment scheduling*, organization of examinations and staff (workfow management), provision of patient data and examination parameters, creation of radiology reports, documentation and coding of activities, and statistics. A special feature is the close connection to the modalities: The *RIS* typically provides a working list (i.e., patient name and requested examination) for the modalities and receives confrmation on the completion of a radiologic examination from the modalities. Due to these special features, software for *RIS* typically comes from specialized vendors.


**Table 3.5** Set of functions and related features typically to be supported by *radiology information systems*

## *3.4.6 Picture Archiving and Communication Systems (PACS)*

Even if radiologists occasionally still produce images on flm, the modalities generally produce digital images. Digital images are stored in *picture archiving and communication systems (PACS)*. These application components allow the storage, retrieval, management, manipulation, and presentation of large amounts of image data and their quick communication from the storage medium to the attached radiologists' workstations. Image data can also be sent from the *PACS* to the ordering departments or facilities in a teleradiology network, for example. Quick communication may require a prefetching strategy to retrieve image data from slower storage devices and to provide it to faster devices well in advance to the situation in which they will be needed.

Application software products for *PACS* also comprise means for image processing and 3D reconstruction. They are often offered by vendors, which also offer physical data processing systems such as storage, networks, and modalities.

Alternatively, *vendor-neutral archives* (VNAs, Sect. 3.9.3) can be used to store image data and other patient-related documents. VNAs are connected to the *RIS*, the image processing components of the *PACS*, and other application systems using communication standards (especially DICOM). The use of the communication standards here follows the rules provided in the Integrating the Health care Enterprise (IHE) profles for sharing documents (Sects. 3.7.2.4 and 3.7.2.6).

Obviously, *RIS* and *PACS* in one health care facility should be closely connected. They should also have a tight connection to the facility's *patient administration* 


**Table 3.6** Set of functions and related features typically to be supported by *picture archiving and communication systems*

*system*, *MDMS*, *CPOE system*, and the *patient data management system (PDMS)* in order to allow quick access to reports and imaging pictures from every unit.

Table 3.6 sums up the functions being supported and the features usually offered for these functions.

## *3.4.7 Laboratory Information Systems (LIS)*

Similar to radiology departments, laboratories exist both as functional areas within a facility, for example, a hospital, and as independent enterprises that offer their services to other health care facilities. Laboratories perform *execution of lab examinations* (Table 3.7). During *execution of lab examinations*, specimens of patients (e.g., blood sample, tissue sample) are used. In contrast to radiology departments, no *appointment scheduling* is required in laboratories. Depending on the type of laboratory, different examination technologies are used (e.g., chemical analysis of blood samples, microscopical analysis of tissue samples). Chemical analysis is usually done using automated equipment. Depending on the order, the sample is usually distributed automatically to various analytical devices, which are regularly checked for their precision in order to conform to quality management requirements. In addition, the laboratory physician checks all results of a sample for plausibility (so-called validation).

Application systems supporting *execution of lab examinations* and offering features as in Table 3.7 are called *laboratory information systems (LIS)*.

*Laboratory information systems* support the management of the whole analysis procedure: receipt of the order and sample, distribution of the sample and order to the different analytical devices, collection of the results, technical and clinical validation of results, communication of the fndings back to the ordering department or facility, and general quality management procedures. The validation of laboratory results is more effective when patient-related clinical data (e.g., recent diagnoses, drug medication) are accessible to the laboratory physician. The *LIS* in a particular health care facility should therefore be closely connected to the facility's *MDMS*, *patient administration system*, *CPOE* system, and *PDMS*. Application software products for *LIS* are usually also sold by specialized vendors.


**Table 3.7** Set of functions and related features typically to be supported by *laboratory information systems*

**Table 3.8** Set of functions and related features typically to be supported by *operation management systems*


## *3.4.8 Operation Management Systems (OMS)*

Invasive procedures for patients at a particular health care facility are performed in the operating rooms (ORs) at this facility. Usually, patients stay in the OR for only a few hours. During this time, they are prepared for the operation, the operation is performed, and fnally, for a period of time after the operation, the patients' state is monitored. This results in performing the functions listed in Table 3.8.

Application systems supporting functions and offering features as in Table 3.8 are called *operation management systems (OMS)*.

*Operation management systems* support *execution of operations* as a specialization of *execution of diagnostic and therapeutic procedures*. They allow operation date and time to be assigned and should therefore be available on the wards as well as in the offces and management units of the OR. Depending on the planned operations, an operation plan can be created for a day or a week. The data necessary for effcient planning are the diagnoses of the patient, the planned operation (medical procedure), the surgeons and other staff involved (human resources), the planned time for operation (appointment), and the available OR (space). Therefore, the *OMS* should be closely connected to the *MDMS*.

A vast amount of data must be documented during each operation, including the members of the operating team, the operative procedure, the date and time, duration of the operation, materials (e.g., implants) used, and other necessary data to describe the operation and its results. Surgeons cooperate tightly with anesthesiologists during the operation. For their documentation, anesthesiologists need a lot of data, which must usually be documented by surgeons and vice versa. To avoid transcriptions, an *OMS* should therefore also provide supportive features for anesthesiologists in an integrated way.

Usually, the planning data are taken from the operation planning component to be updated and completed during and after the operation. These data can be used to create an operation report, which may be completed with further comments by the surgeons. Therefore, word processing capability is needed. Operation data needed for billing must be coded and then communicated to the administrative application components. The *OMS* should also allow extensive data analysis (e.g., operation lists for junior surgeons).

## *3.4.9 Patient Data Management Systems (PDMS)*

Patients in critical situations are treated in intensive care units (ICU). These patients are generally in an unstable state and within seconds may enter into a lifeendangering situation. Thus, the detailed and complete presentation of all vital parameters (e.g., blood pressure, pulse, breathing frequency) is required for a successful therapy. This is only possible when automated monitoring devices continuously measure and record various parameters. In addition, parameters that could point to the initial deterioration of the patient's status should be automatically detected and should lead to an immediate alert of the treating health care professionals. Functions being performed in ICU are outlined in Table 3.9.

Application systems supporting functions and offering features as in Table 3.9 are called *patient data management systems (PDMS)*.

*Patient data management systems* are specialized to automatically monitor, store, and clearly present a vast amount of patient-related clinical data in ICUs. They also support scoring (e.g., TISS,3 SAPS4 ) and may offer features for decision support and various statistical analyses.

<sup>3</sup>Therapeutic Intervention Scoring System.

<sup>4</sup>Simplifed Acute Physiology Score.


**Table 3.9** Set of functions and related features typically to be supported by *patient data management systems*

After transfer to a regular ward, a short summary of therapies on the ICU should be created and communicated to the application components used at the ward. In addition, a connection to the application components for *order entry* and result reporting is necessary. Software for a *PDMS* is sold both by specialized vendors and by vendors that also offer automated monitoring tools.

Intensive monitoring is also required during anesthesia. Therefore, *PDMS* are also used in the preparation, execution, and follow-up of operations. *PDMS* for anesthesia have additional features for anesthesia planning and execution.

## *3.4.10 Enterprise Resource Planning Systems (ERPS)*

As part of the *administration of health care facilities*, there are functions to be performed that differ little from those in facilities in other industries. These include, in particular, the functions *controlling*, *fnancial accounting*, *facility management*, *human resources management*, *quality management*, and *supply and disposal management* (Table 3.10).


**Table 3.10** Set of functions and related features typically to be supported by *enterprise resource planning systems*

Application systems supporting functions and offering features as in Table 3.10 are called *enterprise resource planning systems (ERPS)*. *ERPS* enable health care facilities to manage their fnancial, human, and material resources.

A close connection is needed to the facility's *patient administration system*, in particular, but also to the other application components mentioned before, in order to obtain, for example, billing data and legally required diagnoses and procedure codes. Most of the application software products used for *ERPS* in health care facilities are not specifc to health care but are also used in other industries outside health care where similar administrative functions have to be supported.

One major goal of the *ERPS* is the documentation and billing of all accountable services. The types of data needed and the details of billing depend on the country's health care system.

## *3.4.11 Data Warehouse Systems (DWS)*

For decision-making, the management of a health care facility (Table 3.11) requires up-to-date information about the facility's operation as a whole. The management is, for example, interested in answers to questions such as: What are the top ten diagnoses of the patients treated in our facility? Which department of the facility


**Table 3.11** Set of functions and related features typically to be supported by *data warehouse systems*

causes the highest material costs? In which department do patients stay longest on average?

In order not to jeopardize the performance of these application systems with resource-consuming data analyses, dedicated application systems are used that extract the required data from the source application systems at certain intervals and then make them available for analysis. Application systems that support functions and offer features as in Table 3.11 are called *data warehouse systems (DWS)*.

*Data warehouse systems* are also used to support medical research, especially for clinical trials. Loading data, for example from the *MDMS*, *LIS*, *RIS*, or *CPOE system* into a *DWS*, the recruitment of patients for clinical trials, and the statistical *evaluation* of patient data can be effectively supported.

*Data warehouse systems* can help to answer the aforementioned questions by pooling management-relevant data from other systems such as the *ERPS* and the *CPOE system* and providing means to analyze these data through data mining techniques. A *DWS* supporting *management of health care facilities* is often called a business intelligence system.

Extracted data in the *DWS* have been transferred and aggregated into a suitable format and then actively loaded into the data warehouse (push principle). A specifc request on the data will only access data already loaded into the data warehouse.

An ISO standard exists which provides implementation guidance for data warehouses in health information systems [6].

## *3.4.12 Document Archiving Systems (DAS)*

As part of the function *archiving of patient information*, long-term archiving is a particular challenge for both paper-based and digital documents. Application systems supporting this function and offering the features listed in Table 3.12 are called *document archiving systems (DAS)*.

Dependent upon the type of data and national laws, patient-related data must be stored for up to 30 years. For *long-term archiving*, confdentiality, availability, and integrity of the data according to the Open Archival Information System model (ISO 14721) must be guaranteed. Availability means that data must be retrievable and readable at any time throughout the archiving period. To ensure integrity, data must be complete and unchanged. In health care, authenticity of the author and the time of the creation of a document are important aspects of integrity. For example, unauthorized alteration of the date of creation results in the loss of integrity of


**Table 3.12** Set of functions and related features typically to be supported by *document archiving system*

archived data. The conditions of confdentiality, availability, and integrity can hardly be met by the individual application systems introduced before. This is especially true as these application systems cannot be expected to be in use for up to 30 years. It therefore makes sense to assign this task to a dedicated application system and copy the documents to be archived there.

*Document archiving systems* offer long-term archiving of patient-related and perhaps of other data and documents. Archiving is based on sustainable standardized data formats, document formats, and interfaces. The *DAS* also provides standardized indexing of document content and regular updates of storage media. Qualifed electronic signatures, for example in compliance with European directive 1999/93/EC [7], can be used to guarantee long-term integrity of stored data in case the *DAS* is enabled to renew outdated signatures and hash algorithms. *DAS* are typically closely linked to all application systems that generate data and documents which it must store for a long time. It obtains copies of data and documents from those systems, indexes them, and stores them, while enabling fast retrieval. Paperbased documents can be integrated through scanning, which makes it possible to eliminate the physical space needed for paper-based archiving. *DAS* can typically archive not only text-related documents but also images, videos, and other multimedia data. All these documents may be stored using established non-proprietary industry standards such as:


It makes sense to use vendor-neutral archives (Sect. 3.9.3) to realize *DAS*.

Patient-related medical data and documents stored in the *DAS* in a facility have to be made available to the medical management documentation system of this facility in order to enable their users to directly access information from earlier patient contacts.

## *3.4.13 Application Systems for Patients and Informal Caregivers*

In contrast to the previously described application systems in health care facilities, application systems for patients and informal caregivers cannot be structured that clearly by the tasks they perform and their typical functionalities. This is due to the fact that there are a multitude of mobile health (mHealth apps), desktop, and browser applications available that support patients in better understanding, dealing with, and (independently) managing their health condition. In addition to application systems dealing solely with self-diagnosis, *self-treatment*, or knowledge management, there are also a number of combined application systems, i.e., mHealth apps, that provide knowledge, support therapy, and assist patients in keeping their appointments at the same time. Some typical types of application system for patients and informal caregivers are described below. These are examples and by no means represent an exhaustive list.

#### **3.4.13.1 Patient Portals**

*Patient portals* are offered by health care facilities. They are primarily available for patients of this facility and informal cargivers to provide them with an overview of their health data, organize documents, and actively manage themselves. *Patient portals* can also be used to improve communication between health care professionals and patients. For example, relevant documents can be uploaded to the portal by patients before admission to a hospital or rehabilitation center and are made available there for early access. This improves not only the preparation for admission to a facility but also creates transparency of information, which is crucial for patient empowerment.

*Patient portals* support *medical knowledge management* including document management and, in some cases, also *appointment scheduling*. Thereby, they offer features such as those described in Table 3.13.

In addition to *patient portals* that focus exclusively on the needs of patients, there are also special portals for relatives. Such portals mostly support relatives in their role as informal caregivers. Simple portals for relatives usually provide information about a disease and how to deal with it. They are therefore also referred to as information platforms. Information can be provided in different ways, ranging from simple structured information sets to comprehensive e-learning services. More comprehensive portals for relatives also offer opportunities for *medical knowledge management* as previously described for *patient portals*.


**Table 3.13** Set of functions and related features typically to be supported by *patient portals*

#### **3.4.13.2 Telemonitoring Systems**

*Telemonitoring systems* are provided by health care facilities or by health insurance companies. They are primarily used to monitor patients' state of health remotely, reinforcing a patient-centered health care approach. The aim is to detect critical or conspicuous changes in the state of health in order to be able to address them as quickly as possible. Therefore, they are used particularly frequently in post-acute monitoring of patients, for example, after discharge from a hospital or a rehabilitation center, as well as in chronic diseases, such as with Mr. Russo's heart failure.

In principle, *telemonitoring systems* acquire a patient's health data, transmit it to a health care professional, and represent it to that professional (and in some cases also to the patient) in an appropriate form. The monitoring of the health status can be done either in real time or time-delayed. In addition to a clear visualization of the recorded data and its provision to a treating health care professional, some *telemonitoring systems* also handle the partial or complete analysis of the data. Health care professionals either receive aggregated information on a patient's health status or receive alerts as soon as a critical value or abnormal changes in health status are detected.

*Telemonitoring systems* thus support the patient's self-management abilities and *self-diagnostics* through continuous monitoring. Thereby, they offer features such as those described in Table 3.14.

The range of functions and complexity of *telemonitoring systems* varies greatly in practice. For example, simple *telemonitoring systems* only record a patient's state of health via manual data entries by patients, for example, by querying the symptoms associated with a disease. There are also a number of *telemonitoring systems* that, in conjunction with other systems such as a blood pressure monitor, can also record vital parameters and evaluate them independently in combination with other patient-related data. The range of functions thus extends from simple observations to comprehensive application systems which, in addition to recording, also perform analysis, management, and initial diagnosis.

*Telemonitoring systems* are increasingly supplemented by functionalities for patient education and patient coaching.

#### **3.4.13.3 Self-Diagnosis Systems**

Simple *self-diagnosis systems* in the form of web applications or mHealth apps are used to provide people suffering from ailments with information about what illness they might have. The so-called symptom checker systems provide possible diagnoses or disease information matching the symptoms entered by the patient in just a few minutes. This works particularly well for simple, common diseases. For rarer, more complex conditions, however, the results provided are signifcantly less precise.

*Self-diagnosis systems* are also used in various disciplines for remote diagnosis, for example, when a patient is unable to visit a physician. In this case, *self-diagnosis systems* are considered telemedicine applications that are used for communication between physicians and patients.

*Self-diagnostic systems* support *self-diagnostics* and self-management of patients. Thereby, they offer features such as those described in Table 3.15.

*Self-diagnosis systems* usually operate on the basis of artifcial intelligence and neural networks. They automatically analyze a patient's entries, from simple texts to image data. As mentioned before, some of these application systems transmit their results automatically or at the request of a patient to a (specialist) physician in the sense of telemedicine. Such *self-diagnosis systems* are used, among other things, in dermatology for the prevention and early detection of skin diseases such as skin cancer.


**Table 3.14** Set of functions and related features typically to be supported by *telemonitoring systems*



It is important to note that no form of *self-diagnosis systems* can replace professional assessments by physicians, not to mention professional treatment. Instead, the aim is to involve patients to a greater extent in the care process (patient empowerment) and to improve communication between patients and health care professionals.

#### **3.4.13.4 Self-Treatment Systems**

*Self-treatment systems* range from simple treatment-assisting systems to strengthen patients' self-management skills to individual therapy systems that can be used either as a complement or as an alternative to standard therapy. In addition to software-based mHealth apps, desktop and web applications, more and more hardware-based systems are also being used. Through the implementation of different sensor technologies, these enable not only the guidance of therapies, but also a monitoring of the state of health or even an evaluation of therapeutic measures.

Overall, the feature set of *self-treatment systems* varies greatly and depends, among other things, on the intended use and the specifc area of application. Table 3.16 shows some typical features to support patient *self-treatment*.

Information-only application systems represent the simplest form of *selftreatment systems*. These simply contain descriptions to educate patients about one or more alternative therapies. For example, Mr. Russo can access information about a healthy diet for lifestyle changes or learn about ways to reduce stress, such as yoga exercises. More sophisticated *self-treatment systems* include not only information and guidance but also concrete instructions on how to perform a therapeutic or complementary measure. For example, Mr. Russo is not only recommended certain yoga exercises, but they are also explained in detail, for example, in the form of texts or instructional videos. Thereby, Mr. Russo can exercise along with the application system and mark off individual workouts to save his progress. Embedded assessments, whether automated based on sensor technology or as queries via manual data entry, also help to record the current state of health and changes caused during the therapy period. These can either be feedback to the patient or be forwarded in the form of telemedicine applications to a health care professional for further interpretation and subsequent therapy adjustment.

Reminders to perform an activity, such as exercise sessions or taking medication, are also integral parts of *self-treatment systems*.


**Table 3.16** Set of functions and related features typically to be supported by *self-treatment systems*

## *3.4.14 Other Application Systems*

In addition to the application systems introduced so far, we can usually fnd many other types of application systems, often serving specifc needs of the respective health care facility and its departments. For example, depending on the size of the hospital, a hospital may have its own pharmacy department which needs a *pharmacy information system* to supply wards and patients with the right drugs in the right dose. Depending on the specializations of a hospital, there may be, for example, a *cardiovascular information system (CVIS)* or a *dialysis information system*, which are specialized *MDMS*.

Table 3.17 lists some of these specifc application components. This list is not intended to be exhaustive, however.

Until now, we have focused on "classical" application systems, i.e., software installations in health information systems primarily supporting the functions as listed in Sect. 3.3. But there is an increasing number of installations of software in health care settings that primarily control medical devices. Hence, medical devices can increasingly be considered to be application systems and in many cases to be specialized *MDMS*. Consequently, they not only provide information (e.g., fndings and images) via respective interfaces, but also need information from other application components (e.g., patient, case, order). This close interconnection is often referred to by the term "converging technologies." Due to the considerable risks for patient safety, reasonable diligence must be exercised when integrating these converging technologies into the computer-based part of health information systems.


**Table 3.17** Further specifc application components in health information systems (examples)

## *3.4.15 Clinical Information Systems (CIS) and Electronic Health Record Systems (EHRS) as Composite Application Systems*

Not every health information system contains an *MDMS*, an *NMDS,* or a *CPOE system* as separate, identifable application systems. Instead, these components are often closely integrated modules of the so-called *clinical information systems (CIS)*.

*Clinical information systems* are also often called *electronic health record systems (EHRS or EHR systems)*. As introduced in Sect. 2.10, the electronic health record (EHR) is a complete or partial health record stored on an electronic storage medium. Given this defnition, every computer-based application component supporting the *execution of diagnostic and therapeutic procedures* or other subfunctions of *patient care* (e.g., *MDMS*, *outpatient management system*, *NMDS*, *PDMS*) contains at least a partial EHR. In the *CIS* of a certain health care facility, these partial EHRs are often integrated and made available to the professionals from all areas of the facility to provide one harmonized view on the data of a patient. Because of this harmonized view, the term *electronic health record system (EHRS)* as a particular application component has become quite common.

## **3.5 Logical Tool Layer: Data Integrity**

In the previous section, we saw that there can be very many different types of application systems in health information systems. Therefore, we are dealing with very complex information systems in health care. In information systems, it is generally important to make sure that the data stored is correct. In complex health care information systems, this is a particular challenge.

For the correctness of data in health information systems, we use the term *data integrity*. There are many aspects of data integrity. Here we want to focus on the following aspects:


In this section, you will learn more about these aspects of data integrity.

Object identity originates from object-oriented programming and means that an object has an existence that is independent of its value. Thus, two objects may look the same, i.e., they have the same value, but can still be different. Applying this to the representation of entity types in a database leads to the requirement that the representation of every entity must be uniquely identifable. In a health information system, this is especially important for entity types such as "patient" and "case," but also for "fnding," "order," and all other entity types (Sect. 3.2.3). This identity is needed, since all data need to be assigned to a specifc patient and their cases. For example, if application components exchange information on the patient entity "Mr. Russo," they must be sure they are communicating about the same entity (the "real" Mr. Jakub Russo, not another patient who has by chance the same name).

Experience has shown that object identity of the entity type "patient" can be guaranteed only when every patient receives a unique number, the PIN. The PIN should have no internal meaning. That is, it is created continuously and is usually numerical. Past attempts to generate a PIN from data collected from the patient, for example, from the date of birth and the name, have led to considerable problems, for example when a date of birth is corrected and thus the PIN also changes. In this case, object identity could be compromised. For example, the "real" Mr. Jakub Russo has the PIN 3050.1515 that is used throughout all application components and in the communication between them when referring to this real person.

Similar actions should be taken for the entity type "case." A CIN, which should also have no apparent meaning, should be assigned for every case. If all application components of a health information system ensure that a case identifed with a CIN is always assigned to the correct patient, the CIN can be used as an identifer for the patient. During order entry, for example, the CIN can then be used to uniquely identify a patient when ordering a laboratory test.

In every health care facility, assigning a PIN and a CIN to a patient is part of the function *patient identifcation* of this patient, a subfunction of *patient admission*. The PIN must be used in all parts of the hospital, and thus in all application components, for the identifcation of the patient and will also be used during future visits. Since PIN and CIN are assigned during *patient admission*, only one admission has to be performed and only one PIN has to be assigned to patients during their visit, regardless of which ward they are treated on. For example, Mr. Russo was assigned a PIN (and CIN) when he was frst admitted to Ploetzberg Hospital. This PIN will now be used whenever Mr. Russo is admitted to this hospital again.

This works well if there is exactly one dedicated application system supporting *patient admission*, namely the *patient administration system*. The *patient administration system* must have direct access to a database that holds data allowing the reidentifcation of all past patients and cases in the hospital. To have this *MPI* as part of the *patient administration system* is an obvious choice.

*MPI* are also required for *patient identifcation* in HIS which cover more than one health care facility. In tHIS, data about a patient are to be used across different facilities, for example, when exchanging data between two hospitals or between a hospital and a nursing home. *MPI* as a dedicated application system provides a unique transinstitutional identifcation of a patient across separate *patient administration systems*. This transinstitutional PIN is cross-mapped by the MPI to the PINs of the respective health care facilities.

Object identity provides a unique identifcation for entities. Referential integrity builds on top of this and means the correct assignment of entities to each other. For example, a number of cases must be correctly assigned to a certain patient, or laboratory fndings must be assigned to a given case. Object identity is the precondition for referential integrity.

Object identity for patients and cases needs to be achieved among all application components, regardless of whether they are computer-based or not. Without object identity, there is no referential integrity, and without referential integrity, results cannot be related back to the correct patient. Therefore, without the correct usage of the PIN and CIN, the pure installation of technical means such as communication networks and computer systems is practically useless, as the precondition for data integrity is not met.

Object integrity and referential integrity form two elements of data integrity. The third element we want to look at is data consistency. *Data consistency* means that copies of data on the same entity are identical.

In health information systems architectures with many different application systems, the application systems often use the same data on patients and thus store them redundantly in their own database systems. This means that there are copies of data (e.g., of patient name, patient diagnosis, laboratory fndings) that represent the same information about one particular entity. We call these copies of the same data "duplicates."

Obviously, these duplicates are supposed to be identical in all application systems where they are stored. In this case, we denote these duplicates as consistent. If the data are not identical and thus represent contradictory information, we call the duplicates inconsistent. *Transaction management* tries to make sure that data are and stay consistent—we then talk of replicates, meaning that copies of data are automatically held consistent. In health information systems having only one application system with only one database system, no redundant data exist, as all data are the so-called unicums—they only exist once.

## **3.6 Logical Tool Layer: Architectural Styles**

As defned in Sect. 2.11, the architecture of an information system describes its fundamental organization, represented by its components, their relationships to each other and to the environment, and the principles guiding its design and evolution. The components of health information systems comprise functions, business processes, and tools for data and information processing, especially application components.

With regard to the functions and processes, there are considerable differences between information systems of different kinds of health care settings. For example, there are very clear differences in functions and processes between hospitals on the one hand and patients' home environments on the other. However, there are very great similarities at the domain layer of hospital information systems, as the hospitals' goals and thus the hospitals' functions are in general the same. All functions presented in Sect. 3.3 should thus be supported in every hospital information system. Remember that, from our point of view, these functions can be supported by non-computer-based or computer-based application components.

However, even for the same kind of health care setting, there are usually signifcant differences in information systems architectures with respect to the types and relationships of tools used and the way they are integrated. We will introduce a multidimensional taxonomy, which can be used to characterize different styles of architectures. This taxonomy will help to describe real health information system architectures, to compare them, and to assess them.

We will frst take a look at the logical tool layer and later (in Sect. 3.10.3) look at health information systems' architectural styles at the physical tool layer. In doing so, we concentrate on the computer-based part of health information systems.

*Architectural styles* at the logical tool layer of the computer-based part of health information systems are characterized by the


These facets will be introduced as semantic dimensions which can be used to categorize hospital information systems' architectures.

## *3.6.1 Number of Databases: Central vs. Distributed*

Application systems of health information systems may store data on certain entity types persistently. Usually, a database is used for this purpose. We will use the number of databases storing data in health information systems as the basis to distinguish possible data distribution styles at the logical tool layer of health information systems: the *DB1* and the *DBn* style.

#### **3.6.1.1 DB1 Architecture**

If a health information system (or its sub-information system) comprises only one database to store all patient-related data, we call this a *DB1 architecture* (Fig. 3.24). This single database system is often called the central database system for this (sub-)information system.

The precondition for the *DB1 architecture* (also: *central architecture*) is that all application systems store their data only in the central database and that this database is open for accessing and storing data there. There are two ways for realizing this style:

• The application software products of the application systems originate from the same vendor who designed the database, they are all self-developed by a health care facility, or they have been developed particularly for this health care facility.

• There exists an appropriate API along with standards to query and manipulate the database. This can be achieved by using an *open platform* (Sect. 3.9.3) where the database schema on the persistence layer does not need to be known.

If application components from different vendors are used and the previous conditions are not fulflled, the so-called DBn style can usually be found.

#### **3.6.1.2 DBn Architecture**

In health information systems based on commercial software components from several different vendors, we can usually fnd *DBn architectures* (also: *distributed architecture*). This means that several application components store data on certain entity types persistently and contain their own database systems. Figure 3.22 presents this style.

As a consequence of this style, patient-related data must be stored redundantly in different application components. For example, data on the entity types "patient" and "case" may be stored in different application components, such as the *patient administration system*, *LIS*, and *RIS*.

In this architecture, great emphasis must therefore be placed on the consistency of redundant data (Sect. 3.8.1). For example, the architecture must defne which system is the responsible source for which data elements. It may be useful to state, for example, that data on patient and case may be created and changed only by the *patient administration system* (however, the other components may locally store and use a copy of these data). We will discuss these topics in more detail in Sect. 3.9.1.

**Fig. 3.22** DBn style with multiple application systems, each with its own database system, using 3LGM2 symbols. The cloud in the center indicates that some as yet unknown means is needed to link the components

It is quite obvious that in DBn architectures consistency of redundant data can only be achieved if the application systems are able to communicate with one another, i.e., they must be interoperable. We will discuss interoperability of application systems in more detail in Sect. 3.7.1.

#### **3.6.1.3 Mixed DB1 /DBn Architectures**

In practice, you will hardly fnd health information systems with a pure DB1 style. Even if one central application component with the central database has been installed in order to support the functions, it is hardly possible to stop implementation of further application components; and those application systems will usually come with their own databases. Hence, even if a considerable part of these health information systems is DB1 styled, they are in sum actually DBn styled. Similarly, even DBn styled health information systems contain sub-information systems which are DB1 styled.

We will refer to the mixed style by the string "DB1 /DBn ".

## *3.6.2 Number of Application Systems: Monolithic vs. Modular*

In the simplest case, the overall health information system consists of only one computer-based application system which supports most of the functions. This application system would then look like the one rock on which the whole hospital rests. Respective health information systems are commonly called *monolithic*. We will refer to this style by the string "*AC1* ". Of course, this application component contains the central database and AC1 correlates with DB1 . A graphical representation of such a (DB1 , AC1 ) architecture is presented in Fig. 3.23.

Especially in large health care facilities such as university medical centers or even in home settings, however, one application component is usually not suffcient to support the different functions. This leads to architectures with a multiplicity of application components, which can be denoted by *ACn* and are called *modular architectures*.

**Fig. 3.23** (DB1 , AC1 ) architecture using 3LGM2 symbols. The rectangle denotes the application system that contains a database system (denoted by the cylinder)

**Fig. 3.24** (DB1 , ACn ) architecture with multiple application systems, using 3LGM2 symbols. Only one application system (in the center) contains a database system

However, modular architectures can still be DB1 architectures: For example, the *RIS*, the *LIS*, and the patient administration system are connected to a certain application system which shares one single database management (Fig. 3.24). The application system in the middle may be an *open platform* (Sect. 3.9.3). Such (sub-) information systems can be described by (DB1 , ACn ).

Anyhow, there is still widespread use of a combination of many application components and many databases, i.e., of (DBn , ACn ) architectures, as in Fig. 3.22.

## *3.6.3 Number of Application Software Products and Vendors: All-in-One vs. Best-of-Breed*

The terms "homogeneity" and "heterogeneity" are commonly used to describe whether a health information system consists of somehow similar components or very different ones. A practical measure is the number of application software products installed or the number of vendors delivering these products to a health information system. We denote a *homogeneous architecture*, i.e., a (sub-)health information system with software from only one vendor, as *V1* . Consequently, independent of the number of application systems, V1 -HIS use only application software products that all come from the same vendor. On the contrary, *heterogeneous architectures* comprise software from several vendors and are denoted as *Vn* .

Obviously, (DB1 , V1 ) architectures are more common than (DB1 , Vn ) architectures.

An (ACn , Vn ) architecture where the different application systems are based on software from different vendors is commonly denoted as *best-of-breed architecture*, pointing to the fact that the health care setting combines the "best" application software products from different vendors. This best-of-breed architecture is typically DBn although (DB1 , Vn ) architectures could become more common in the future.

On the contrary, a monolithic (AC1 , V1 ) architecture and even an (ACn , V1 ) architecture emphasizes that the health care facility selected only application software products from exactly one vendor to support as many functions as necessary. This homogeneous architecture is also called *all-in-one architecture*.

## *3.6.4 Communication Pattern: Spaghetti vs. Star*

Application systems that are part of an ACn architecture have to be connected as we discussed before. One way would be to directly connect those application systems that need to exchange certain patient-related data.

For example, if data on the entity types "patient" and "case" are needed in the *patient administration system* in the *RIS* and in the *LIS*, direct communication links between these components seem to be a possible solution. Hence, a communication link allowing for the transfer of patient data between the *patient administration system* and the *RIS* may be introduced. Consequently, when connecting several application systems, this will lead to an increasing number of bidirectional communication links. This architecture is called *spaghetti* style. All these different links must be supported and managed. As the number of application systems rises, the number of links grows nearly exponentially. The maximum number of communica-

tion links between n application components (*n* ≥ 2) is *x n x* = − ∑1 1 . We denote architec-

tures with this spaghetti-styled communication pattern as *CPn* . Figure 3.25 presents a (DBn , ACn , Vn , CPn ) architecture.

To reduce the large number of links, one can use smarter methods and tools to organize and implement the interoperability of application systems, for example, by installing an application system in the "middle", ensuring communication between the application systems.

For example, most hospital information systems following the DBn style use a *communication server*. By using a communication server, no direct communication links between application systems are needed. Links are needed only between the application systems and the communication server. The number of links that must be managed can consequently be low—ideally, only n links exist for n application systems.

We call this style *star architecture* and denote it as *CP1* . Figure 3.26 presents a (DBn , ACn , Vn , CP1 ) architecture. Note that star architectures do not necessarily contain communication servers, as the center of the star may also be an application system with a central database. Consequently, (DB1 , ACn ) architectures will also be CP1 architectures. Furthermore, we may call a service-oriented architecture (SOA)

**Fig. 3.25** (DBn , ACn , Vn , CPn ) architecture with multiple application systems, using 3LGM2 symbols, with several bidirectional communication interfaces. This representation is also called a "spaghetti" architectural style

**Fig. 3.26** (DBn , ACn , Vn , CP1 ) architecture with multiple application systems connected by a specifc application component, using 3LGM2 symbols. This representation is also called a "star" architectural style

with one application component serving as a broker or as a service bus a CP1 architecture as well. But for AC1 , this concept obviously does not make sense and neither CP1 nor CPn should be applied.

## **3.7 Logical Tool Layer: Interoperability and Standards**

As we saw in the previous section, health information systems are characterized by containing many application systems, i.e., they are usually of the ACn architecture type. And we saw that they can only guarantee data integrity in their health information systems if the application systems communicate with each other. Even more, this communication is the absolute prerequisite for the health information system to fulfll its task of ensuring the necessary data and knowledge logistics.

Thus, application systems need to be able to communicate—they need to be interoperable. Without interoperability, no meaningful integration of application systems within health information systems is possible. Integration means that the application systems are put together in such a way that the resulting information system—as opposed to its parts—displays a new quality. There are various kinds and aspects of integration, as we will discuss later in Sect. 3.8.

Interoperability in general is the ability of two application systems to exchange information with each other and to use the information that has been exchanged. Saying that two application components are interoperable thus indicates that (1) they have interfaces and (2) they are—on the most minimal level of interoperability—basically able to send and receive data via these interfaces.

In this chapter, you will frst be given an introduction into various aspects of interoperability within health information systems. Costs of the implementation and maintenance of health information systems can be signifcantly reduced when the application system's interfaces are based on standards. In Sect. 3.7.2, we will discuss recent interoperability standards and how they support the various aspects of interoperability.

## *3.7.1 Aspects of Interoperability*

How does communication really work? If two application components want to meaningfully communicate, a consensus must exist about four aspects:



This leads to four aspects of interoperability: technical interoperability, syntactic interoperability, *semantic interoperability*, and process interoperability (Fig. 3.27).

We will describe interoperability as a property or capability of application systems or of application software products used to install application systems.

Please note that the four aspects of interoperability do not allow dichotomous statements about application systems or application software products. Rather, they are concepts that can exist to varying degrees and relate to different aspects. For example, semantic interoperability may refer to more aspects in one application system than in another application system without completely denying semantic interoperability in the other application system.

#### **3.7.1.1 Technical Interoperability**

Technical interoperability, as the most minimal level of interoperability, is the ability of an application system to send or receive "bits and bytes" in a reliable and standardized way and thus possesses respective interfaces and implements protocols. The data may be sent or received as a fle, string, or continuous stream. Files and strings of data can be considered messages (Sect. 2.2). Web technologies such as REST application programming interfaces (APIs) provide such technical interoperability.

If the application system wants to send messages to or receive messages from an application system installed on a different computer, these computers need to be physically interoperable (Sect. 3.10.2) and the interfaces have to be able to interact with lower layer communication protocols at the physical tool layer as defned in the ISO/OSI reference model (Sect. 3.10.2).

For example, the *patient administration system* is technically interoperable if it possesses an interface for reliably sending or receiving a message to or from another interoperable application system such as the *RIS*. The message exchange must work regardless of whether both application systems are installed on the same or on different servers.

To be able to consider the structure, content, or meaning of the exchanged messages, higher levels of interoperability are needed.

#### **3.7.1.2 Syntactic Interoperability**

An application system is syntactically interoperable if it is technically interoperable and additionally uses a predefned structure for the exchanged messages. Thus, when technically exchanging a data fle, string, or stream, specifc data elements can be identifed, such as beginning and end of a message or of message segments containing data on certain entity types such as "patient," "case," or "fnding." Syntactically interoperable application systems are thus able to obtain information from received messages—exchanged data becomes machine-readable.

A quite simple approach to structure exchanged data are data formats such as CSV (comma-separated values) or XML. However, these formats cannot support syntactic interoperability by themselves, as they need additional agreements or rules, for example, on where to fnd the patient's name or birthdate in the given dataset.

Communication standards such as Health Level 7 Version 2 (HL7 V2), DICOM, and Health Level 7 Clinical Document Architecture (HL7 CDA) provide a data or document format together with clear rules on where to fnd which data element. Thus, they support syntactic interoperability. All these communication standards are presented in more detail in the next sections.

For example, the *patient administration system* is syntactically interoperable if it is technically interoperable and can use HL7 V2, specifcally the message type "administrative admission." Thereby, the *patient administration system* can send Mr. Russo's administrative data to the *RIS*. If the *RIS* is syntactically interoperable as well, it will be able to incorporate these data in its database.

#### **3.7.1.3 Semantic Interoperability**

Two application systems are semantically interoperable if they are syntactically interoperable and can exchange information (in the form of messages) that can be meaningfully interpreted by both and processed further.

We can also say that the information transferred is not only "machine-readable" but also "machine-processable." This means that the application system can "understand" the content of messages and act accordingly, for example, by using data for automatic decision support. Beyond mere syntactic agreement between two actors and agreement on data types or structures defned in a reference model for data representation, a prerequisite for this mutual understanding is a homogeneous, jointly agreed defnition of the underlying content concepts, for example, a clinical concept such as "systolic blood pressure." Such concepts are called detailed clinical models. To achieve this, two application systems must adhere to such content models which defne possible content (e.g., as openEHR archetypes) or actual content (e.g., as HL7 FHIR resources or openEHR templates, Sect. 3.7.2.8).

Modelers who create detailed concept representations which are used for communication between systems or for querying data repositories frequently draw on already existing specialized terminology standards or terminologies such as

SNOMED and LOINC (Logical Observation Identifers Names and Codes) to enhance their models. Thus, they support semantic interoperability, as they provide a common and unambiguous vocabulary within shared information models (Sect. 3.8.2) between application systems. LOINC and SNOMED are presented in more detail in Sects. 3.7.2.9 and 3.7.2.10.

An *information model* describes the entity types and their relationships at a conceptual level, independent of any specifc implementation or protocols. Information models are intended for designers. In contrast, a data model is defned at a lower level of abstraction. Data models are intended for implementers of databases.

In addition to these two terminologies, also known as nomenclatures, there are numerous classifcations in medicine. Classifcations are mainly used for statistical purposes, for example, counting similar objects, or for grouping similar treatment cases together for billing purposes. Occasionally, however, they are also used to support semantic interoperability although they were not actually designed for this purpose.

Some examples of classifcation systems used in health care are presented in Table 3.18.

Please note that semantic interoperability cannot be achieved without technical and syntactic interoperability. The ability to exchange structured messages is the precondition for exchanging meaningful data. If application systems have agreed to exchange, for example, LOINC codes within a message, the receiver can automatically extract these LOINC codes. To be semantically interoperable, the application system must be able to interpret the extracted LOINC code and understand the context in which it is used.

#### **3.7.1.4 Process Interoperability**

Finally, process interoperability addresses whether application systems are able to cooperate in certain organizational contexts, especially in certain processes, by meaningfully exchanging information. Such processes may involve, for example, ordering a radiological examination and then sending back the fndings or providing a document for use outside one's own facility and then using the document from


**Table 3.18** Examples of classifcation systems used in health care

outside. Process interoperability depends on successful technical, syntactic, and semantic interoperability.

An application system is interoperable with respect to a particular process if it is syntactically interoperable and capable of both sending all messages required for the collaborative processing of that process and correctly interpreting the messages received. Through this communication, the application system must be able to correctly fulfll the role it has been assigned in this process.

The more business-related the processes to be supported are, i.e., the more they correspond to the function in Sect. 3.3, the more semantic interoperability an application system must have.

Process interoperability requires the ability to handle many send and receive operations in a specifc way and sequence required by the supported process. Since the communication standards mentioned so far essentially refer to individual sending and receiving operations, regulations are required that relate to the complex organizational context and the processes to be supported. IHE provides such regulations in the form of the so-called profles. The IHE organization offers to review and certify application software products to determine whether they are interoperable with respect to a specifc process and profle.

Although these profles merely describe the use of existing interoperability standards, they have now taken on a normative character. For this reason, we also describe IHE in Sect. 3.7.2.5.

## *3.7.2 Interoperability Standards*

As said before, the costs of the implementation and maintenance of interfaces within heterogeneous health information systems can be signifcantly reduced when standards for interoperability are used. Furthermore, mapping processes are usually accompanied by a loss of information or semantics.

Within the logical tool layer of health information systems, there exist standards for syntactic interoperability (also called communication standard or message standards), for semantic interoperability (common information models, terminology standards), and for process interoperability. For technical interoperability there is, for example, the already mentioned REST standard at the logical tool layer. This is complemented by so-called protocols at the physical tool layer, which will be discussed in Sect. 3.10.2.

An abundance of standards exists, some covering more than one aspect of interoperability. Thus, it is not trivial to assign them to the above-mentioned levels.

As the most widely implemented and well-established standards, HL7 V2 messages and DICOM will be described. However, there are more. HL7 CDA is a standard for structuring medical documents and contributes to syntactic interoperability. HL7 FHIR simplifes the exchange of clinical data between heterogeneous application systems using web technologies for data transfer. DICOM allows digital images and related metadata to be shared. IHE in general focuses on workfow processes and enables process interoperability by providing guidelines on how to apply other standards, for example, DICOM, HL7 V2, and HL7 FHIR. In particular, Integrating the Health care Enterprise Cross-Enterprise Document Sharing (IHE XDS) focuses on content-agnostic, i.e., encapsuled, sharing of documents within and across different health care organizations. For the exchange of bio-signals and vital signs between point-of-care devices, the ISO/IEEE 11073 standard is available. openEHR focuses on the representation of clinical information in detailed clinical models and allows for the creation of a semantically fully defned EHR. SNOMED CT is a universal, multilingual clinical terminology for supporting semantic interoperability that includes more than one million relationships of different types between concepts. LOINC also supports semantic interoperability and is the most widely used standard for measurements and tests in health care, for example, laboratory tests. The Clinical Data Interchange Standards Consortium (CDISC) provides a number of standards, of which ODM-XML (Operational Data Model) is well-known for the representation of clinical research (trial) data and metadata, being widely used in electronic data capture (EDC) systems.

We will now discuss some of these standards in more detail. The list is by no means complete, with new standards emerging and others disappearing frequently, as well as current ones changing.

#### **3.7.2.1 Health Level 7 Version 2 (HL7 V2)**

Health Level 7 Version 2 (HL7 V2) [9] is the most-implemented communication standard in hospital information systems for the transfer of messages with data on the entity types "patient" and "case" and the other entity types as described in Sect. 3.2.3, but excluding image data.

HL7 V2 has been maintained by the international standards organization Health Level Seven International (HL7) since the 1990s. It can be best considered as a standard to support mainly syntactic interoperability between application systems.

HL7 describes event types and dedicated message types that are exchanged between application systems when triggered by a specifc event.

HL7 assumes that a message is sent from application system A to another application system B through the occurrence of an event of certain event type (Fig. 3.28). The message type that is used for the message depends on the occurring type of event. The message type describes the structure of the sent message and determines the meaning of the individual parts of the message.

Following the arrival of the message, application system B confrms the receipt of the message through a receipt message (ACK) that is sent back to application system A. If a communication server such as in Sect. 3.9.2 is used to send a message, for example, from the *patient administration system* to the *LIS*, then the communication server frst takes over the role of the receiving application system B. As

a second step, the communication server, as the sending application component A, sends the message to *LIS*, which takes over the role of B.

HL7 possesses an extensive catalog of event types. For example, A01 describes the event "admission of a patient," A02 "transfer to another organizational unit," A03 "discharge of a patient," and R01 "completion of an examination result."

In addition, HL7 provides a list of standardized message types, such as *admission, discharge, and transfer* (*ADT*), for messages related to admission, discharge, and transfer of patients. Other message types are ORM for a general order message (e.g., ordering a radiological examination), ORU for an unsolicited observational result (e.g., radiology report), and BAR for patient accounting message.

Message types are assigned to event types. For example, if the *LIS* in the laboratory of a hospital registers the occurrence of an event of type R01, then it can send a message of message type ORU.

All HL7 V2 messages are structured into segments, with each segment containing felds. For example, the ADT message contains at least the following segments: message header (MSH), event description (EVN), patient identifcation (PID), and patient visit information (PV1). With each segment, the relevant information is provided in different felds, each separated by "|". The following example shows a very simplifed pattern of an ADT message where a patient is admitted to a specifed ward:

```
MSH|SENDING COMPONENT|RECEIVING COMPONENT|DATE OF MESSAGE|
EVN|A01|DATE OF EVENT|
PID|PATIENT IDENTIFIER|NAME^FIRST NAME|BIRTH OF DATE|SEX|
PV1|PATIENT CLASS|WARD ID|DATE OF ADMISSION|
```
Despite this standardization, the use of "plug and play" equipment is often not possible due to various reasons. On the one hand, HL7 leaves users with a certain degree of freedom with regard to semantic interoperability. Consensus must be reached between the communicating application systems, whether, for example, the choices "male." "female," "other," and "unknown" for gender can be documented as "m", "f", "o", and "u", with "0", "1", "2", and "3", or in some other fashion. Furthermore, there also exists the problem of using catalogs of terms. For example, if a *CIS* wants to order a radiological examination, it must have an up-to-date copy of the service catalog of the radiological unit.

On the other hand, manufacturers of application software products sometimes offer HL7 interfaces to their products that cannot send or receive all required event types and/or all necessary message types. In this case, a thorough analysis is necessary before deciding on a purchase.

Finally, there exist different sub-versions of HL7 V2 (2.1, 2.2, 2.3, 2.4, 2.5, 2.6) which partly differ in their defnition of message content.

When a message was constructed in accordance with the previous explanations, it is left up to the particular implementation how communication between the physical data processing systems will occur. A message can then, for example, be written in a text fle or transported by disk or using an FTP fle transfer. The exchange format and protocol for technical interoperability at the physical tool layer is to be decided on in every single communication link.

#### **3.7.2.2 Clinical Document Architecture (CDA)**

The Clinical Document Architecture (CDA) is an XML-based document standard for storing and exchanging clinical content in the form of documents (e.g., a discharge letter, a lab fnding). CDA was developed and is maintained by the HL7 organization and has been accredited by ANSI, the American National Standards Institute.

CDA is one element of the Health Level 7 Version 3 (HL7 V3) standard. HL7 V3 is a message standard developed by the HL7 organization in the 2000s. Unlike HL7 V2, where messages were developed in a pragmatic way, messages in HL7 V3 are derived from an information model, the so-called HL7 Reference Information Model (RIM).

The message encoding within CDA is based on XML, thereby supporting syntactic interoperability. CDA documents are persistent records of medical information (such as diagnostic fndings, discharge summaries, or lab reports). CDA supports free text as well as fully structured, machine-processable information, thus also supporting semantic interoperability. Document templates (so-called implementation guidelines) defne CDA-based document structures for specifc use cases such as a discharge summary or a radiology report. CDA is used in several countries for sharing clinical documents on a national level.

CDA documents comprise two parts: the CDA header that presents metadata on the document such as sending institution, patient name, and type and date of document; and the CDA body that contains the specifc information (e.g., the lab result).

The following example (adapted from [10]) shows a very simplifed extract of an XML-based lab result message from the CDA body. The elements specify the type of observation (glucose 12 h fasting), the time of the observation (February 15, 2021, 7.30 a.m.), and the status (the observation is completed). The value for the actual result is shown in the value element (182 mg/dL), and the data type is PQ = physical quantity. The glucose lab value is also given in coded form (1554–5), which is a code from the LOINC system ("LN," Sect. 3.7.2.10). Using LOINC codes supports semantic interoperability. LOINC is uniquely identifed by the LOINC Object Identifer (OID) ("2.16.840.1.113883.6.1"). All relevant terminology systems in health care possess a unique OID which allows application systems to exchange the information which terminology systems is being used.

```
 <observationEvent>
 <id root="2.16.840.1.113883.19.1122.4">
 <code code="1554-5" codeSystemName="LN" codeSystem=
    "2.16.840.1.113883.6.1" displayName="GLUCOSE^POST 12H"/>
 <efectiveTime value="202102150730"/>
 <statusCode code="completed"/>
 <value xsi:type="PQ" value="182" unit="mg/dL"/>
 </observationEvent>
```
Since HL7 V3 is not compatible with HL7 V2 and a "translation" between both formats is not trivial, HL7 V3 is primarily used for transinstitutional message exchange for which version 2 is not well suited. Both HL7 versions can be expected to coexist for a longer time.

#### **3.7.2.3 Health Level 7 Fast Health care Interoperability Resources (HL7 FHIR)**

HL7 FHIR (Fast Health care Interoperability Resources) is a recent HL7 standard based on the experience from other HL7 standards that was developed in and has been continuously updated since 2014. The standard is built upon web technologies, most notably REST APIs and simple HTTP operations. The focus is on sharing medical data in terms of transferring them from one application system to another in a standardized manner and thus make medical data portable. FHIR supports technical interoperability (by using web technology standards), syntactic interoperability (via clearly defned resources), and semantic interoperability (via an underlying information model and the use of reference terminologies).

The two basic building blocks are information models called "resources" which represent clinical, identifying, or fnancial information as well as APIs. The basic resources follow the so-called 80/20 approach, i.e., to meet 80% of the needs by implementing 20% of the requirements. FHIR neither aims to cover all clinical information nor to implement an EHR but pragmatically focuses on frequent, generic use cases. HL7 develops the FHIR specifcation and manages the resources, for which it also defnes a number of rules on how to create them. FHIR provides terminology linking and validation.

To implement specifc clinical use cases, generic FHIR resources are adapted into "profles," or more specifc information models. Thus, institutional or local adaptations are implemented, albeit with a trade-off towards loss of interoperability.

Apart from supporting data sharing by providing mechanisms for interfacing different application systems with likely diverging underlying information models and persistence structures, a native "FHIR server" implements a set of APIs and resources and allows for operations, for example, to create, update, or search resources.

#### **3.7.2.4 Digital Imaging and Communications in Medicine (DICOM)**

Digital Imaging and Communications in Medicine (DICOM) [11] is an open standard maintained since the 1980s by the DICOM Standards Committee of the National Electrical Manufacturers Association. DICOM addresses the integration requirements of the medical imaging sector.

DICOM supports technical interoperability at the physical tool layer (by defning network protocols such as Transmission Control Protocol/Internet Protocol (TCP/ IP)), syntactic interoperability (by its message formats), and—to some extent semantic interoperability (by an underlying information model).

DICOM defnes not only fle and message formats for all types of medical imaging modalities (e.g., computed tomography, digital X-ray, magnetic resonance imaging, ultrasound, nuclear medicine imaging), but also a network protocol at the physical tool layer with a set of well-defned network services. These services permit, for example, an imaging modality to retrieve a "worklist" describing the patients to be examined from the *RIS*, to transmit the images and X-ray dose information created during an examination to the *PACS*, to confrm that the images have been archived successfully (and can thus be deleted locally), and to notify the *RIS* that the imaging procedure has been completed. Other services permit a diagnostic workstation to retrieve current and prior imaging studies, to print a hardcopy on a medical printer, or to store a report and results of measurements performed on the images. Unlike HL7 V2, the DICOM standard defnes a complete network protocol stack (based on TCP/IP, Sect. 3.10.2) using effcient binary encoding and, optionally, image compression techniques. The capabilities of two communicating systems (such as the services and encodings supported by both systems) are dynamically negotiated whenever a new network connection is initiated, which permits a tight integration because systems can to some degree adapt to the capabilities of their communication peers. DICOM has gained widespread acceptance in the medical imaging sector as well as in all medical disciplines that rely heavily on digital images (in particular radiology and cardiology).

It should be noted that the *RIS* is also dependent on messages from the *patient administration system* and must also send, for example, billing data there. As discussed above, this communication should be carried out on the basis of HL7 V2. Orders from wards and outpatient units will also most likely reach radiology as HL7 messages, whereas the results and images will come back as DICOM messages. The common initiative IHE (Sect. 3.7.2.5) has taken on the task of settling this complex interplay.

#### **3.7.2.5 Integrating the Health care Enterprise (IHE)—Integration Profles**

Integrating the Health care Enterprise (IHE) is an organization founded by medical professional societies in 1998 together with the health care IT industry [12]. Its aim is to improve the integration of application systems in health care and to check and certify if application software products to be used for the application systems have the process interoperability needed for this integration.

The approach taken by IHE is to analyze typical work processes occurring in health care. IHE identifes the application systems involved in these processes and the information that should be exchanged between these application systems to support the diagnostic and therapeutic processes as good as possible. For example, IHE has defned working processes in the form of "integration profles" for areas such as cardiology, pathology, radiology, and pharmacy. It has also defned integration profles for the exchange of clinical documents between different health care facilities (IHE XDS, Sect. 3.7.2.6).

IHE then selects existing standards, i.e., especially HL7 V2 and DICOM, for each "transaction" (information exchange between application systems) and restricts the options offered by these standards for each transaction so that plug-andplay interoperability becomes possible.

By defning work processes, IHE supports process interoperability. Together with standards such as HL7, HL7 CDA, HL7 FHIR, openEHR, and DICOM, it indirectly supports syntactic and semantic interoperability.

IHE furthermore offers comprehensive test software enabling vendors to test their products' interfaces for IHE-conformant process interoperability and organizes large cross-vendor testing events called "IHE Connectathons" (from "connection" and "marathon").

IHE is not a standards body as such but flls a very important gap by selecting the most appropriate set of standards for a typical clinical workfow. It reduces the indeterminacy of the way of interaction, for example, between HL7 V2 and DICOM, by proposing clear rules for their joint use. The resulting technical specifcations are published annually as the IHE Technical Frameworks.

Although the profles are not communication standards, they gain normative character through their increasing dissemination and can be regarded as quasistandards for the use of communication standards.

**Fig. 3.29** IHE XDS.b actors and interactions (simplifed), using the example of a radiology report. #1–#6 indicate order of messages

#### **3.7.2.6 IHE Cross-Enterprise Document Sharing (XDS)**

One of the above-mentioned technical frameworks is the IT Infrastructure Framework (ITI), which specifes standards-based implementations for exchanging clinical information. Among other things, it describes how to share documents between different health care organizations. IHE Cross-Enterprise Document Sharing (IHE XDS) is used, for example, for the Austrian ELGA (national EHR) and partly in the German Medical Informatics Initiative.

IHE XDS defnes neither the content of these documents nor their internal structure, making it "content-agnostic." Instead, it defnes actors along with their interactions and integration profles of both these components. IHE XDS.b is a prominent integration profle defning affnity domains and actors.

Figure 3.29 shows the actors in this profle and their interactions. A source system (e.g., an *RIS*) provides a new document, for example, a radiology report on Mr. Russo, along with its metadata to the document repository. This document is then registered in a document registry. A document consumer, for example, another clinical application system, such as the *MDMS*, at a different site in the health care network, can query the document registry to locate a relevant document and then query and subsequently retrieve this document from the decentral document repository. Document repositories are usually decentral, while the registry is central.

#### **3.7.2.7 ISO/IEEE 11073**

The ISO/IEEE family of standards for the exchange of data between medical devices comprises, for example, a standard for exchanging bio-signals and vital parameters between point-of-care devices [13]. Furthermore, the standard enables a dynamic exchange and reconfguration of devices and remote control, for example, of infusion pumps.

Medical devices can be considered as combining an application system at the logical tool layer with a dedicated physical data processing system at the physical tool layer, which is often also called an appliance.

ISO/IEEE 11073 can be used, for example, to receive and display data from infusion pumps, respirators, ECGs, etc. on patient monitors in the ICU and for integrating medical devices in operating rooms. It is also used for receiving data from mobile wellness devices (e.g., ftness tracker) and personal health applications (e.g., diabetes app).

ISO/IEEE 11073 supports technical interoperability by defning a complete communication protocol stack and, for example, includes binary encoding of data that is optimized for near-real-time transmission. It also supports syntactic interoperability by defning the formatting and syntax for the exchanged messages.

While ISO/IEEE 11073 enables the exchange of especially vital parameters between the application systems of the medical devices, HL7 V2 and DICOM facilitate the data exchange between the application systems mentioned in Sect. 3.4. However, it is also necessary to be able to exchange data between these worlds. For example, patient demographic data is also required for the devices, and vital parameters should be able to be transferred to the EHR. Gateways are used to realize this communication.

#### **3.7.2.8 open Electronic Health Record (openEHR)**

openEHR (open Electronic Health Record) is an open standard specifcation which focuses on the standardized representation of clinical information in EHRs. It has been maintained by the openEHR Foundation since the early 2000s and supports semantic and syntactic interoperability.

The specifcation follows a detailed (maximum) clinical information modeling approach and provides a formalism—the archetype defnition language (ADL) to defne *archetypes* as the basic building blocks representing clinical concepts. Furthermore, it includes the archetype query language (AQL), which—while syntactically similar to the ubiquitous SQL—operates on clinical concepts and unlike SQL—requires no knowledge of the persistence data structures (e.g., database schemata).

openEHR follows a two-layer modeling paradigm, fundamentally separating clinical content from technical details. The frst layer is the reference model, which describes the smallest logical blocks along with their implementation, for example, data types and structures or basic EHR components. As part of the archetype model, the second layer defnes the domain model representation in a maximum approach, meaning that an *archetype* (e.g., blood pressure or height), as the most basic and self-contained clinical concept, should serve all potential uses of this concept within the health care domain.

In other words, archetypes are reusable as semantic building blocks in different contexts without further modifcation. Within an archetype, each single item or data

instance can be linked or bound to a terminology (e.g., LOINC or SNOMED CT). Archetype classes include "composition", "section," and "entry," whereby the latter again includes "observation," "evaluation," "instruction," "action," and "cluster." To create more complex information units on the basis of these interchangeable building blocks in the context of specifc use cases, openEHR uses templates. An operation report, the results of an assessment test, or a form/document could, for example, be represented as templates, each assembled using archetypes just like construction bricks. A number of tools support the collaborative creation of openEHR archetypes and templates by clinicians and modelers, their governance, and the automated creation of software artifacts from them, which can be used in application systems of all kinds.

openEHR enables the defnition of a complete EHR along with methods to structure the EHR and manipulate its contents, for example, by writing (adding) compositions to the record. It also includes versioning. The open specifcation includes openly available REST APIs for programmers and vendors and supports several implementation/representation formats. Finally, it makes it possible to build a full, vendor-independent EHR within and across health care facilities.

#### **3.7.2.9 Systematized Nomenclature of Medicine Clinical Terms (SNOMED CT)**

SNOMED was developed in the 1970s and is maintained by SNOMED International, a non-proft international standards organization. SNOMED CT (Systematized Nomenclature of Medicine Clinical Terms), frst published in 2003, is currently the most comprehensive terminology in the health domain and is used in many countries worldwide. Users must obtain a license for use. The nomenclature aims to support the development of high quality, precisely defned content by standardizing medical terms and by providing ontological components such as associations and relationships between encoded concepts and entities.

SNOMED CT supports the semantic interoperability of application systems. It can be used for encoding and exchanging machine-processable data. SNOMED CT codes (like other codes from terminology standards) can be embedded in information models of other standards such as HL7 FHIR or openEHR.

SNOMED CT consists of concepts, descriptions, and relationships. A concept represents a unique clinical concept such as diabetes mellitus (disorder), which has several children concepts, such as diabetes mellitus type 1 or diabetes mellitus type 2, and so on (Fig. 3.30). Each further level in the hierarchy represents a more specific concept (partitive or taxonomic relationship). Associations between concepts may be of different types, for example, is-a (diabetes mellitus is a disorder of the endocrine system) or finding-site (structure of the endocrine system). SNOMED CT also contains synonyms and is available in multiple languages.

**Fig. 3.30** SNOMED CT example of associations between concepts. (Taken from the SNOMED CT browser [14]; use of SNOMED CT is with the permission of SNOMED International)

#### **3.7.2.10 Logical Observation Identifers Names and Codes (LOINC)**

Logical Observation Identifers Names and Codes (LOINC) is a widely used terminology system for health measurements, tests such as laboratory and clinical tests, and observations. LOINC was developed in the 1990s and is maintained by the Regenstrief Institute in the United States [15].

The system defnes unique names, codes, and identifers that can be used in application systems or within communication messages such as HL7 or DICOM messages as well as in CDA documents (Sect. 3.7.2.2 shows an example of this), openEHR archetypes, or FHIR profles. LOINC thus supports the semantic interoperability of application systems.

LOINC codes are constituted of six components, for example, LOINC code 1554-5:


The LOINC "long common name" for this code example is "Glucose [Mass/ volume] in Serum or Plasma --12 hours fasting."

#### **3.7.2.11 Clinical Data Interchange Standards Consortium (CDISC)**

The Clinical Data Interchange Standards Consortium (CDISC) spans a wide variety of standards, which are mainly—but not exclusively—designed for and used in clinical studies and trials in the pharmaceutical industry. CDISC standards were developed in the late 1990s and are maintained by the non-proft Clinical Data Interchange Standards Consortium.

CDISC standards are free to use and cover different domains and parts of the complete process to develop clinical products such as new drugs. The use of some of these standards is mandatory for reporting and submitting results from clinical trials to regulatory authorities, for example, to the FDA (U.S. Food and Drug Administration).

Common CDISC standards include the "foundational standards," which cover all necessary processes within research studies. Along the evolution of a research study, these standards cover planning (model for planning: Protocol Representation Model), data acquisition (model for data collection: Clinical Data Acquisition Standards Harmonization), organizing and managing data (e.g., Study Data Tabulation Model (SDTM), model for Questionnaires, Ratings, and Scales), and for data analysis (Analysis Data Model).

SDTM is the standard in which study data are submitted to regulatory authorities. Apart from these foundational standards, CDISC also supports a controlled terminology and includes widely used standards for data exchange, such as ODM-XML.

By employing these CDISC standards, researchers can achieve syntactic and semantic interoperability, share their data and metadata, and use a variety of software solutions (e.g., different EDC systems and analytical tools) along the study process.

## **3.8 Logical Tool Layer: Types of Integration**

Interoperable application systems can be joined together, i.e., integrated, in such a way that their combination has new properties that the application systems did not have on their own. Integration is a union of parts making a whole, which—as opposed to its parts—displays a new quality.

Integrating application systems lead to integrated health information systems. An integrated computer-based health information system typically offers better support for functions and business processes than a non-integrated information system consisting of isolated application systems. In non-integrated information systems, users may, for example, need to manually transfer data from one application system to another, or inconsistencies between data representations and semantics may exist that hinder the multiple use of data.

There are various ways of integrating application systems, resulting in different types of integration. Each type of integration leads to specifc new properties of the information system. In this section, you will learn about the following types of integration in more detail:


Note that the basic prerequisite for all types of integration is that the application systems to be integrated must be technically and syntactically interoperable so that communication is possible at all.

While interoperability makes a statement about a single application system or about a single application software product and its specifc properties and capability, integration always refers to a set of application systems and the way they are connected in a specifc information system.

## *3.8.1 Data Integration*

*Data integration* is achieved in integrated health information systems when data that have been recorded and stored once in one application component are made available in a coherent and uniform way wherever they are needed, i.e., in other application components, without having to be reentered. Data integration has two effects:


In DB1 architectures, i.e., architectures with a central database, data integration is comparatively easy to achieve. *Open platforms* are a technology that can be used to implement this even in (ACn , Vn ) architectures (Sect. 3.9.3).

In case of a decentralized DBn architecture, data integration and a uniform view on the data is more challenging. Transaction management and communication servers are integration technologies suitable to meet this challenge (Sects. 3.9.1 and 3.9.2).

Data integration helps to increase data consistency (Sect. 3.5) and to reduce unnecessary double data entry:

Assume that Mr. Russo was treated in the cardiology department, and a detailed medical history was collected and entered into the *MDMS*. Now Mr. Russo's health is deteriorating dramatically, and he must be moved to the ICU of the same hospital. If the medical history needs to be documented again, in case the information from the cardiology department cannot be accessed, there would be no data integration. If the ICU can assess and add data to the existing medical history, regardless of where and in which application system the already existing data was entered, data integration is achieved. In this example, the medical history may be sent from the *MDMS* to the *PDMS*, either directly or via respective integration technology and tools (Sect. 3.9).

To support data integration with non-computer-based application components, computer-based application components need to be able to print out data or to scan data such as paper-based documents (e.g., signed patient consent documents or a paper-based order entry form).

## *3.8.2 Semantic Integration*

Like data integration, *semantic integration* is concerned with data. Semantic integration is achieved when semantically interoperable application systems actually use the same system of concepts, i.e., they interpret data the same way. For example, when the sending application system uses the abbreviation "GOT" for a lab value, but the receiving application system does not know this code and uses "ASAT" for the same concept instead, then semantic integration is not achieved.

To achieve semantic integration of application systems, the application systems must agree on the way that information is represented, for example, within a hospital or a network of care facilities. This means that there needs to be an agreement on a common information model, for example, on Mr. Russo's blood pressure. This agreement comprises two aspects: We need to agree on how to actually represent the data values (e.g., systolic and diastolic values) by data. And we also need to agree on the underlying clinical concept and represent metadata such as the context of the measurements (resting blood pressure or exercise test), the measurement method (cuff or intra-arterial on an ICU), and so on. Contextual information can make a huge difference. For example, for a *clinical decision support system (CDSS)*, which tries to interpret the blood pressure values to determine whether the value is normal or abnormal in a specifc situation. Development of such information models is time-consuming multi-professional work, and agreeing on and maintaining them requires effort and strict governance of models. In the long term, however, these information models reduce tedious and costly mapping work and maintenance of mapping tables between application systems. Furthermore, it enables the reuse of data in contexts that differ from the original scenario in which the data was recorded, for example, for research or clinical decision support (CDS).

Thus, for semantic integration, the application systems must agree on some common terminologies. However, using terminology systems such as LOINC, SNOMED, or ICD (Sect. 3.7.1.3) does not guarantee semantic integration. Instead, for real semantic integration, application systems must also agree on common information models. Such common information models contain a set of abstract concepts (e.g., patient, case, observation, entry, series of pictures) which are close to our concept of entity types and their relationships among each other. They thus try to formally represent the reality of health care through a set of concepts and their relationships. If two application components agree on the same information model, exchange of information and thus semantic integration are facilitated. Both openEHR (Sect. 3.7.2.7) and HL7 FHIR (Sect. 3.7.2.3) enable the creation of common information models, derived from a reference model.

Semantic integration can be elegantly and thoroughly supported by health data dictionaries. Such medical data dictionaries are central catalogs of health-related concepts and terms that offer the possibility of representing the semantic relationships among all data stored in a health information system and of linking that local vocabulary to internationally standardized nomenclatures and knowledge sources ("terminology linking" in openEHR). Such health data dictionaries (sometimes also called Medical Data Dictionaries, MDD) can be independent application components or part of existing application components.

## *3.8.3 User Interface Integration*

*User interface integration* is guaranteed when different application systems represent data and organize their user interfaces in a unifed way. For example, different application systems should display the patient's name always at the same place on their user interface. Icons for patients should code gender with the same colors. Alerts and warnings should be presented using the same colors and layout. Or the birthdate of a patient should also be displayed in the same format (e.g., yyyy-mm-dd).

The responsibility for integrating application systems in such a way that user interface integration is achieved lies with *tactical management of information systems* (Sect. 4.4). Especially at the specifcation stage of a new application software product, the relevant user interface requirements must be clearly described. This can be supported by user interface guidelines that are commissioned by standardization, governmental agencies, or leading health IT vendors.

## *3.8.4 Context Integration*

Even if data, semantic, and user interface integration is ensured, problems can arise when users use multiple application systems on one workstation, as the user and patient context may become lost through the change from one application system to another. *Context integration* is achieved if the context is preserved when the application system is changed. Or, more generally, the aim is that a task that has already been executed once for a certain purpose, such as login to a component or selecting a patient, does not need to be repeated again in the information system in order to achieve the same purpose.

Assume that the nurse Peter Smith frst wants to order a lab examination for the patient Jakub Russo at his workstation before documenting certain nursing procedures. The nurse would frst log in to the *CPOE system* and create the user context "Peter Smith." Then Peter searches for the patient Jakub Russo and orders the requested examination for him. This creates the patient context "Jakub Russo." For the next task, the nurse would have to start the *NMDS*. Without context integration, the user context "Peter Smith" would not be created in this application system

automatically and Peter would have to log in again. And without context integration, Peter would have to again select the patient and restore the patient context "Jakub Russo" before being able to document the nursing procedures. Context integration would be achieved when both login (then also called "single sign-on") and patient selection (maybe called "single patient look-up") do not have to be repeated again, even when changing the application system.

Health Level 7 provides a standard for single sign-on and single patient lockup, called CCOW (Clinical Context Object Workgroup).

## *3.8.5 Feature Integration*

*Feature integration* is achieved when features needed in more than one application system are implemented only once and can be invoked by other application systems.

In a hospital, for example, *coding of diagnoses and procedures* is a feature that should be supported by the *patient administration system*, the *OMS*, the *RIS*, and the *LIS*. The health information system would display feature integration with respect to *coding of diagnoses and procedures* if only one application component (e.g., the *patient administration system*) provides the features needed for coding diagnoses and procedures and all other application components can invoke and use these features.

Feature integration reduces the need to exchange data between application systems, reduces the danger of inconsistent data, and decreases the need to train users on multiple application systems.

On the technical level, feature integration can be supported by providing the use of features as services within an SOA (Sect. 3.9.3). Those services can be invoked by other application systems.

Overall, feature integration is an important quality characteristic within heterogeneous health information systems, as it allows features to be shared among application systems.

## *3.8.6 Process Integration*

An integrated health information system should support the business processes effectively. From this perspective, *process integration* is indeed the overall vision of integration within heterogeneous information systems, i.e., especially in (ACn , Vn ) architectures.

Process integration is guaranteed when business processes are effectively supported by a set of cooperating application systems showing process interoperability.

Typically, as we have seen, functions of a health care setting are supported by many different, yet interrelated application systems. A user must therefore use different application systems for one task.

For example, while writing the radiological report on Mr. Russo, the radiologist must work with the *CIS*, the *RIS*, and the *PACS*. To enable effective work in this process, these application systems should interoperate as transparently and smoothly as possible. If the radiologist receives the best possible support in report writing, without any interruption due to the heterogeneity of application systems, then we can say the information system is process integrated.

Obviously, process integration builds to some extent on the other integration qualities such as data integration (*CIS*, *RIS*, and *PACS* are able to exchange and jointly use patient diagnosis data without the need to reenter it), user interface integration (e.g., *CIS* and *RIS* have comparable user interfaces), context integration (e.g., when shifting between *CIS* and *RIS*, user patient context is maintained), semantic integration (e.g., procedures documented in the *RIS* are automatically understood by the *patient administration system*), and feature integration (the *RIS* invokes the billing function of the *patient administration system*). Good process integration builds on this, supports comprehensive information logistics, and prevents users from transcription and media breaks.

Process integration can be achieved, among other things, through the adoption of IHE profles (Sects. 3.7.2.5 and 3.7.2.6) on a systematic basis.

Overall, process integration is an important quality characteristic within heterogeneous health information systems, as it describes a situation where different application systems interoperate in an optimal way so that business processes are best supported.

## **3.9 Logical Tool Layer: Integration Technologies and Tools**

To achieve data integrity (Sect. 3.5) and to support various types of integration (Sect. 3.8) in ACn architectures, specifc integration technologies are available. These integration technologies support interoperation of application systems and effcient and secure health information exchange between health care providers, and in some cases also with patients.

In this section, you will learn about transaction management, communication servers, vendor-neutral archives, and SOAs as examples of this kind of integration technologies.

## *3.9.1 Transaction Management*

*Transaction management* ensures that every update of correct data in one or more databases will lead to another state in which the data in these database(s) are still correct. This turns out to be not trivial, especially for complex update operations, the so-called transactions. It is even more complicated in settings of more than one database system, i.e., in DBn architectures.

Transaction management guarantees data integrity and especially data **C**onsistency through **A**tomicity, **I**solation, and **D**urability of any transaction (ACID conditions). Atomicity guarantees that either all of the tasks of a transaction are performed or none of them are; isolation makes intermediary updates of data inside the transaction invisible; and durability stands for persistence of the transaction's results.

The "2-phase commit protocol" was developed for transaction management in DBn architectures. Among other things, this protocol is intended to ensure data consistency in case of data redundancy. In the initial phase, it checks if the transaction can be carried out by all affected application systems. Only if the changes are possible everywhere, they are actually carried out in a second phase in all application systems. To carry out the protocol, the application systems must be tightly coupled by *synchronous communication*, and the database schemata of all involved database systems must be known. For an application system in a health information system, this means that an interface must be provided where both updates and the cancellation of these updates are possible. This is not the case for commercial application components available today. Generally, the individual database schemata of each component are also not known. Due to these reasons, the 2-phase commit protocol to ensure data consistency has usually not yet been implemented within DBn architectures of health information systems.

Nevertheless, to guarantee data consistency, the following more asynchronous approach is typically chosen within a health information system:

For every redundantly stored entity type, one application component is determined as the *primary application system* for this entity type. Thus, data on entities of this type can only be inserted, deleted, or changed in this primary application system. For example, the *patient administration system* is typically the primary application system for the entity types "patient" and "case." Consequently, data on patients and cases can be created, deleted, or changed only in the *patient administration system*. Therefore, this application system is sometimes called the "leading system."

Transactions in a database of the primary application system are carried out without regard to whether the corresponding operations can also be (immediately) carried out in the databases of the other affected application components. *Patient admission* is thereby carried out through the *patient administration system* independent of, for example, what is going on in the *RIS*. It may happen that the *RIS* is not capable of inserting corresponding data on the patient or the case that were sent by the *patient administration system* into its database at the same point in time. The *RIS* is then obliged to catch up on database operations at a later point in time.

## *3.9.2 Communication Server*

A quite simple way of communication between application systems is the asynchronous exchange of messages. *Asynchronous communication* means that the application system sending a message will continue its tasks without interruption even when awaiting a response message from the communication partner. Message exchange generates queues of messages that have to be managed. Besides direct, point-to-point communication between two application systems, tools for managing message queuing can also be used. These so-called queue managers support the sending of messages from the sender to the receiver and the distribution of a single message to numerous receivers (multicasting).

In health information systems, queue managers are typically referred to as communication servers. A communication server is an application system standing at the center of the logical tool layer of a health information system (Fig. 3.31). This architectural principle is also called star architecture (Sect. 3.6.4) and can be found in many health information systems.

Generally speaking, a *communication server* is an application system used for the asynchronous receiving, buffering, and sending of messages. It can also be used to transform messages and monitor the traffc between application systems and may provide intermediate storage of messages in case the intended recipient of the messages is not yet available (e.g., system down). An application system can send a message to the communication server over its communication interface. The communication server will then relay the message to one address or many addresses (multicasting) when these application systems are ready to receive. In the meantime, the communication server buffers the sent messages in a queue (message queuing). In the case that the receiving application system is awaiting messages in a format based on a different interoperability standard than the sending application system sends, the communication server can transform the sent message. The application systems have to provide communication interfaces for sending messages to the communication server and to receive messages from it.

In this way, the communication server is a tool to support data integration in a health information system of (DBn , ACn ) architecture. Furthermore, communication servers prevent (DBn , ACn ) styled health information systems from *spaghetti architectures* and support CP1 architectures. Application components can be more easily exchanged, thus supporting the expandability of the health information system's architecture.

Some communication servers may also provide *synchronous communication*. For this, the sending application system will pause from the time that it sends a message to the time that it receives the respective answer. In this way, communication servers can be used to invoke services as described in Sect. 3.9.4 and to provide feature integration as well.

In health information systems with DBn architecture and redundant data storage, the application components store the data needed for supporting their functions by themselves. This holds especially for data on the entity types "patient" and "case." Consequently, the communication server is used to ensure that every application system will fnd these data in its database system whenever the data is needed without having to request this data from the *patient administration system*. The following example describes how the *patient administration system* and the communication server can be integrated based on asynchronous communication and use of the interoperability standard HL7 (Sect. 3.7.2.1) in order to ensure data integration as well as data consistency regarding the entity types "patient" and "case":

**Fig. 3.31** Architectural style with multiple application systems, each with its own database system, using 3LGM2 symbols. A communication server links the application components

Mr. Russo has just been admitted to Ploetzberg Hospital in the administration unit. Since the *patient administration system* is the primary application system for the entity types "patient" and "case," *patient admission* is exclusively supported by the *patient administration system* (Sect. 3.9.1). Even before Mr. Russo leaves the administration unit to go to the cardiology ward, the following messages are exchanged between the application systems (Fig. 3.31 highlights steps 2 and 3):


A similar process takes place when administrative data on Mr. Russo is updated. If his address changes, for example, this is frst documented in the *patient administration system*. This application system then sends a message on this update to the communication server (2) that multicasts this message again (3), as described above. Since the *patient administration system* is the primary application system of patient and case, all updates of related data must be performed using the *patient administration system*.

By following these processes, data consistency is provided and application systems will have actual data available in case they are needed. Above all, users in the radiology department, for example, can always fnd the administrative data on their patients in their *RIS* without the *RIS* having to make a request to the *patient administration system* beforehand.

## *3.9.3 Open Platforms and Vendor-Neutral Archives*

An application system is called *open platform* if it stores patient data based on open specifcations and open information models and provides open Application Programming Interfaces (API) for storing and querying these data. "Open" in this context means that the specifcations, information models, and interfaces are published and can be used by any vendor.

An *open platform* follows the idea that both data and metadata are stored in a centralized database, with strict separation between application logic and data storage.

The advantage of the *open platform* approach is that other application systems with different functionalities from different vendors can directly work on the same database (DB1 architecture). This facilitates both *data integrity* (Sect. 3.5) and *data integration* (Sect. 3.8.1) even in Vn architectures. The interoperability standard openEHR (Sect. 3.7.2.8) provides a universal, agreed-upon information model.

*Open platforms* were frst used in medical image archives and *PACS,* then typically called vendor-neutral archives (VNAs).

For example, after admitting Mr. Russo to the cardiology ward, blood samples have to be analyzed at the laboratory and radiological images have to be taken. Using an *open platform* as in Fig. 3.24, the LIS and the RIS would be able to access the same database as the patient administration system even if they are from different vendors.

To support communication between *open platforms* and other application systems, standards such as HL7 FHIR, DICOM, or IHE profles are used (Sect. 3.7.2).

While an *open platform* may seem diffcult to introduce in a long-grown environment of different application systems with their own proprietary information models, it reduces the ever-increasing cost of mappings on the communication server side whenever a new application system is introduced. It also eliminates costly mapping processes when migrating patient data from a previous to a new application system. Open APIs also enable new vendors to integrate their application software products in given information systems by using the agreed information models and thus enable a growing "application ecosystem."

## *3.9.4 Service-Oriented Architectures*

Service-oriented architectures (SOAs) represent architectural styles of health information systems that provide the means and tools to use services for the collaboration of application systems. A service is an encapsulated feature provided by an application system in order to be invoked by other application systems (Sect. 2.9).

This results in synchronous communication between application systems, meaning that the process in the invoking application system, after starting the communication with the providing application system, is paused until a response from the partner is obtained.

The *patient administration system* may, for example, store data on the entity type "patient" and may provide a service for retrieving name, birthdate, and address of certain patients. In this case, the patient data is called a resource. Other application systems can access this resource by invoking the retrieve service and handing over a certain PIN. They will then obtain the desired data—if access is granted. Another service may be provided by application systems allowing a message to be sent to these application systems by invoking this service and handing over the message.

Therefore, this technology is very good at achieving data integration and ensuring data integrity. In particular, it facilitates the construction of DB1 architectures using VNAs.

Moreover, the *patient administration system* could provide a service for *patient admission*. The *RIS* could thus invoke this admission service, handing over data on a certain person who should be admitted to the health care facility. As a result, the *patient administration system* executes all necessary actions needed to perform *patient admission*. With such more complex services, feature integration can be achieved in addition to data integration.

When using World Wide Web technology, the resources are identifed by certain Uniform Resource Identifers (URIs). Application systems can provide basic services for GET, PUT, POST, and DELETE operations on their resources by offering the so-called RESTful APIs. For health information systems, resources as well as services for operating on the resources are standardized by FHIR (Sect. 3.7.2.3).

## **3.10 Physical Tool Layer**

Application components are logical tools, and they cannot exist without physical tools as a basis. In an information system, we can describe this basis with the physical data processing systems at the physical tool layer. As stated earlier, physical data processing systems can be human actors, non-computer-based physical tools, or computer systems.

If application components that exchange data and interact with each other are installed on different physical data processing systems at the physical tool layer, these physical data processing systems have to communicate as well, i.e., integration is also needed there.

We will now have a closer look at typical computer-based physical data processing systems and their integration. You will learn about *physical interoperability* and integration and how challenges in terms of availability and security of application systems and data are addressed in the design of communication networks and the construction and operation of data centers.

## *3.10.1 Physical Data Processing Systems*

#### **3.10.1.1 Servers**

Servers are used to provide sophisticated features to clients (Sect. 3.10.1.2). Servers can run databases (database server), they can run the back-end part of application software products (application server), or they can support printing (printer server). Terminal servers run the front-end part of application software products, which traditionally have been implemented on and run by clients. If terminal servers are used, mere terminals (Sect. 3.10.1.2) for displaying output and receiving input are suffcient. Further server types are name servers (for domain name system (DNS) management), DHCP servers (for dynamic IP assignment), mail servers (for email services), and web servers (for website management).

There is a strong trend to virtualize servers. A "real" (i.e., physical) server can simulate lots of the so-called virtual servers. Every virtual server runs a particular instance of an operating system and can be used to implement application software products. Thus, these virtual servers behave nearly identical to physical servers. This approach makes computing power in a data center much more fexible and scalable.

Virtual servers also result from coupling physical servers in order to maximize availability through redundancy. These kinds of coupled servers are called a server cluster. It makes sense to localize the members of the cluster at different sites of the data center (Sect. 3.10.3).

#### **3.10.1.2 Clients and Personal Devices**

Clients comprise all data processing tools that are immediately available to the various user groups within a hospital, for example:


Mobile devices are especially important in health care settings because devices must provide both data and support of functions wherever patients are. This applies not only to health care facilities, but especially to the patient's home environment.

In medicine, there is a plethora of other personal devices in use to capture data from and about individuals, making it available for further processing in application systems. Sensors for recording vital signs such as heart rate, blood oxygen saturation levels or an ECG are not only used in the ICU of a hospital. Smartphones and smart watches also have such sensors and can provide corresponding data. These personal devices also provide sensors for personal identifcation, such as fngerprinting or retinal eye scanning. Smart cards, which are connected via special readers, are also used for identifcation.

Overall, large health care facilities such as a 1500-bed university medical center will have about 4000 clients (PCs) and 3000 mobile devices. This causes not only investment costs, but also enormous maintenance costs. The energy consumption of these devices is also considerable.

If we assume a power consumption of approx. 300 watts for one PC, this results in a total consumption of approx. 1.2 MW (megawatts) for all PCs together. The mobile devices' energy consumption must be added.

#### **3.10.1.3 Storage**

Health information systems must store not only large amounts of data but also very important data that may be crucial for the patients' health and life. This requires storage devices of high capacity and high reliability. The storage media that are used range from magnetic discs for random access to magnetic tapes and optical media for backup and archiving.

Storage devices, regardless of the media used, are not specifcally attached to and exclusively used by certain servers. Moreover, storage area networks (SANs) provide storage services of different kinds to all servers integrated in this network. This technology allows the storage capacities to be scaled up or down quite easily depending on actual storage needs. Additionally, SANs help to maximize availability through redundancy. It makes sense to localize the members of an SAN at different sites of the data center (Sect. 3.10.3).

## *3.10.2 Physical Interoperability and Integration by Communication Networks*

The types of integration introduced in Sect. 3.8 relate to the logical tool layer and, more precisely, to sets of application systems. Let us supplement this catalog of integration types with *physical integration*.

Physical integration refers to a set of physical data processing systems and is guaranteed if the necessary physical communication is possible for each required data exchange. This requires having only one computer, for example, a mainframe, hosting all application systems or having physical interoperability of the physical data processing systems to be connected. For this, the devices must have hardware interfaces for data exchange. In other words, physical interoperability of physical data processing systems is a prerequisite for technical interoperability of application systems that are installed on different physical data processing systems (Sect. 3.7.1.1). In other words, physical integration between physical data processing systems is a prerequisite for any kind of integration between application components.

Communication networks can be implemented by optical fbers, copper cables, and wireless LAN technologies. Different communication protocols such as Ethernet or Token Ring can be used.

The ISO/OSI reference model provides a framework for describing communication between computers at seven levels. Standards for the respective communication protocols are available for each level. With respect to the three-layer graph-based metamodel (3LGM2 ), these seven levels interconnect the physical with the logical tool layer of a health information system. Level 7 may be considered the logical tool layer which corresponds to the name of the communication standard HL7 (Sect. 3.7.2.1). A set of protocols for each of the seven levels is called a protocol stack.

In order to be able to use the mobile devices required in medicine, appropriate wireless networks are necessary. Wireless local area networks (WLAN) are commonly used inside buildings, both in health care facilities and in private environments. Outside buildings, for example to connect ambulance vehicles but also to feed a limited campus of a health care facility, the same mobile networks that are also used for mobile telephony are used. Currently, ffth-generation mobile networks (5G) are being introduced. These enable high data transmission rates but require a close-meshed network of antennas. The health effects of the associated electromagnetic felds are subject to controversial debate.

The network that exclusively connects the physical data processing systems of a facility is also called intranet. Extensive security measures are required at the interface between the intranet and the internet to prevent unauthorized access to the physical data processing systems within the intranet from outside the facility. These include, in particular, the so-called frewalls. Firewalls are physical data processing systems on which incoming and outgoing communication is monitored by software.

To optimize security, the intranet itself is also partitioned into further security zones. Depending on the need for protection and the permitted user group of application systems, the physical data processing systems on which these application systems are installed are assigned to such security zones. Communication into and out of a security zone is also monitored using dedicated hardware.

## *3.10.3 Data Centers*

The servers must fulfll special requirements related to availability, stability, performance, maintainability, and redundancy. For health care facilities, this can only be economically achieved if the servers are centralized in a data center.

The reliability of the data center, with all its equipment and physical data processing systems, is the very basis for the reliability of the health information system as a whole. Although system stability of application components deals with the quality of the software used, system stability must be enhanced by redundancy. Redundancy is not needed at the logical tool layer, however, but at the physical tool layer.

This requires data centers that provide at least two redundant sites as well as mirrored servers and storage devices at each site, a stable energy supply, high-capacity air conditioning, server rooms that are burglar-proof and disaster-proof, and effective means for fre protection. Even if an information management department ensures an effective backup, the continuous operation of the data center through appropriate redundancy is of utmost importance.

Data center staff needs software tools for supervising proper operation of servers, communication network components, PCs and terminals, and the application components running on top of these physical tools.

For two redundant sites of the data center housing the servers of a large academic center, one must expect an energy consumption of 0.5 MW. This energy consumption results not only from the power consumption of the servers but also from the energy requirements of the air conditioning systems, which must dissipate the electrical energy converted into heat. Consideration should therefore be made as to whether the waste heat from the computers can be used for other useful purposes such as heating the facility's domestic water.

These and the previously mentioned fgures on client energy consumption alone make it clear that medical informatics specialists, and information managers in particular, not only have responsibility for good information systems but also for the impact of information systems on the global climate.

Not only the high energy consumption, but also the major technical challenges involved in operating a data center, suggest that smaller health care facilities in particular should consider whether servers in the cloud, and thus commercial data centers, can be used instead of own data centers. However, this requires stable and suffciently powerful communication links. In addition, the data protection regulations of the respective country must be observed. Conversely, large health care facilities can consider whether their own data center can be offered to smaller surrounding facilities for use. The large facility could then become a cloud provider for the smaller facilities.

## *3.10.4 Data Security*

Data security means protecting the data of an information system both from destruction and loss and from illegal use by unauthorized persons. This is particularly important in health information systems for two reasons. Firstly, health data is highly sensitive and represents intimate information about individuals that must never fall into the hands of third parties without the consent of the individuals concerned. Secondly, a health care facility is at risk of becoming completely incapacitated if the data in the patients' health records can no longer be accessed. This can cost lives. Recent cases of the so-called ransomware attacks on hospitals, for example, illustrate the associated dangers. In ransomware attacks, data is encrypted by criminals and a key for decryption is only made available after payment of a ransom.

It is therefore imperative to invest in protective measures at all levels. For example, as mentioned above, communication networks must be protected through their structure and suitable hardware and software, data backups must be performed and the data copy must be protected against attacks, and highly qualifed personnel must be available. We can only hint at the required know-how in this textbook and therefore refer to the relevant, current technical literature and the training and continuing education programs on data security.

In health care facilities, it is the responsibility of the management of information systems to ensure data security, while corporate management must provide the necessary fnancial resources for this purpose.

In the private environment, this responsibility lies with the individuals themselves. It is the task of politics, but also of the professional societies for medical informatics, to ensure that people are informed, educated, and advised.

## **3.11 Examples**

## *3.11.1 A Reference Model for the Domain Layer of Hospital Functions*

The reference model for the domain layer of hospital information systems consists of the subset of functions and entity types described in Sects. 3.2.3 and 3.3 that are relevant for hospitals. The reference model focuses on the activities in *patient care*. Thus, the main enterprise function is *patient care*, and there are maintenance functions supporting *patient care* such as *supply management*, *scheduling and resource allocation*, *hospital administration*, *hospital management*, and *research and teaching* (Fig. 3.32).

Furthermore, the enterprise functions in that reference model bear a relation to each other by entity types which they can update or interpret. To defne entity types within the reference model of the domain layer, the HL7-RIM5 was used.

The Reference Model for the Domain Layer of Hospital Information Systems is available as a 3LGM2 model6 and for this reason can be immediately used for modeling hospital information systems. Following the defnition of reference models in Sect. 2.13, the Reference Model of the Domain Layer can be used as a model pattern for the domain layer of hospital information systems and, additionally, can help

<sup>5</sup> http://www.hl7.org/Library/data-model/RIM/modelpage\_mem.htm.

<sup>6</sup> http://www.3lgm2.de//Modelle/Referenzmodelle\_und\_Beispielmodelle/RM\_DomainLayer\_version2\_English.z3lgm.

Patient admission

Appointment

scheduling

Patient identification

and checking for

recurrent

Administrative

admission

Medical admission

Nursing admission

Visitor and

information services

Patient administration record

record

Hospital management

to compare hospital information systems by means of a uniform terminology used for the domain layer. This means that, for each enterprise function of the Reference Model of the Domain Layer, it is possible to determine the support by application components in different information systems.

## *3.11.2 The Domain Layer of CityCare*

CityCare is a health care network in the city where Mr. Russo and his family live. In CityCare, Ploetzberg Hospital, Ernst Jokl Hospital, and a specialist medical offce for sports medicine cooperate in order to treat patients suffering from joint injuries.

Mr. Russo's son, an amateur football player, injured his knee joint during his last match. Patients suffering from joint injuries frst consult CityCare's primary care sports physician. If the physician suspects that surgery is needed, she orders MRI diagnostics at Ploetzberg Hospital. After receiving the fndings from Ploetzberg Hospital, the sports physician admits patients needing arthroscopic surgery to Ernst Jokl Hospital for further treatment.

Figure 3.33 describes the domain layer of the CityCare scenario. Functions introduced in Sect. 3.3 were used and specialized or decomposed to model the domain layer. The entity types used are described in Sect. 3.2.

**Fig. 3.33** Domain layer of CityCare

All three health care facilities cooperating in CityCare perform activities regarding the functions of *patient admission* and *execution of diagnostic and therapeutic procedures*. These functions performed by each health care facility are modeled only once at the domain layer. Ploetzberg Hospital is the only hospital offering "execution of MRI diagnostics," whereas Ernst Jokl Hospital is the only hospital offering "execution of arthroscopic surgery procedure."

Entity types such as "patient," "case," and "order" that are used or updated in all three facilities are also modeled once at the domain layer. To visualize different health care facilities, labels (see grey rectangles) were used in the 3LGM2 model.

## *3.11.3 The Logical Tool Layer of CityCare*

At the logical tool layer shown in Fig. 3.34, the application systems that are relevant for the described scenario in CityCare and their communication are modeled. For a better overview, the institutional information systems and the jointly used application systems of the network are labeled by gray rectangles.

The specialist medical offce has one application system that is used for *patient administration* and medical documentation. Both Ploetzberg Hospital (PH) and Ernst Jokl Hospital (EJH) have their own *patient administration system* and *MDMS*. These are different installations of different application software products

**Fig. 3.34** Logical tool layer of CityCare

which are therefore modeled as single application systems. For MRI diagnostics, Ploetzberg Hospital additionally uses an *RIS* and an MRI scanner which is also modeled as an application system. Images that are generated by the MRI scanner and all other medical and administrative data from the *MDMS,* the *RIS,* and the *patient administration system* are stored in the Vendor-Neutral Archive PH, an *open platform*. Thus, these other application systems do not need their own database systems. All three facilities access the central EHR system, a *clinical information system*, of the health care network. This EHR system comprises patient information such as diagnoses, fndings, and discharge letters received from all facilities. To manage the PINs from the different facilities, the health care network uses an *MPI* that assigns a transinstitutional PIN for the patients and maps the different PINs of the facilities to this transinstitutional PIN. This is a precondition for being able to build the *EHRS* in the health care network.

The matrix view in Fig. 3.35 shows which functions are supported by which application systems in CityCare. The application system of the specialist medical offce, for example, supports six different functions. We can also identify functional redundancies. For *administrative admission*, for example, all three facilities use different application systems. Within a health care network like CityCare, it would also be possible to support this function with one application system that is used by each facility. Application systems serving solely as an integration technology, such as the EJH communication server, do not need to be linked with functions at the domain layer in 3LGM2 models. For the VNA and the EHR system, no supported functions are modeled either—fnding appropriate functions is part of the exercise in Sect. 3.12.6. For the correctness of the model, application systems are only assigned to "leaf functions" but not to superordinate functions such as "execution of MRI diagnostics."

**Fig. 3.35** Matrix view visualizing the relations between functions and application systems in CityCare

The architecture of Ernst Jokl Hospital (in the left of Fig. 3.34) can be described as a star-based (DBn , ACn , Vn ) architecture. There are at least two major application systems (ACn ), probably from different vendors (Vn ), with their own respective database system (DBn ). The application systems—the patient administration system and the *MDMS*—exchange data via a communication server (star-based architecture) using HL7 V2 messages. Ploetzberg Hospital also features a star-based architecture which is, however, different from Ernst Jokl Hospital's architecture. At the center of Ploetzberg Hospital's (DB1 , ACn , Vn ) architecture, there is a *VNA* implemented as an *open platform* based on uniform information models in the openEHR standard. The hospital's interoperability experts control these information models and stipulate and enforce their use whenever a new vendor system is added. The *RIS* at Ploetzberg Hospital's radiology department communicates with the MRI scanner using the DICOM standard. The DICOM images generated by the MRI scanner as well as the radiological reports that are documented with the help of the *RIS* are stored in the *VNA*.

The institutional information system of the specialist medical offce has a (DB1 , AC1 , V1 , Cn ) architecture because it only consists of a single application system with one database system. The application system combines the functionalities of a *patient administration system* and an *MDMS*. It could therefore be regarded as the *CIS* (or *EHRS)* of a medical practice (Sect. 3.4.15). This comprehensive application system sends orders for radiological examinations or orders for surgical procedures to Ploetzberg Hospital or Ernst Jokl Hospital, respectively. For this, it uses the HL7 V2 standard.

All three care facilities work together in the CityCare health care network, which provides a centralized *EHRS* that can receive as well as provide patient EHR data on demand. For data persistence, the central *EHRS* implements the openEHR standard for highly structured EHR data and an additional database system for documents. To receive patient data, the *EHRS* provides different interfaces for the three facilities in the network: an HL7 FHIR interface for Ernst Jokl Hospital's communication server, an HL7 V2 interface for the specialist medical offce, and a native openEHR interface for Ploetzberg Hospital. For cross-network identifcation of patients, the CityCare network has implemented an *MPI* based on an IHE integration profle. In the future, it is planned to implement a portal both for external physicians and for the patients themselves so they can access their data in the central *EHRS*.

If Mr. Russo presents at Ernst Jokl Hospital, the local physician will look for available information on Mr. Russo in the hospital's *MDMS*. The system can then send a query to the CityCare network, asking for available information on Mr. Russo. The query is sent via Ernst Jokl Hospital's communication server to the network's central *EHR system* using the unique PIN for Mr. Russo. The central *EHR system* sends back Mr. Russo's data using the HL7 FHIR standard to the Ernst Jokl Hospital communication server and the data is forwarded to the EJK *MDMS*.

## *3.11.4 The Physical Tool Layer of CityCare*

At the physical tool layer of CityCare, parts of the data centers of Ploetzberg Hospital and Ernst Jokl Hospital as well as a joint data center of the health care network are modeled (Fig. 3.36). The specialist medical practice only houses three PCs on which the patient management and *MDMS* can be used. The application system is installed on an application server which is hosted by Ernst Jokl Hospital's data center. Both hospitals also host application servers on which the application systems of the respective hospitals are running. For storing data, SANs are used. In the data center of the health care network, there is an application server for the *EHRS* and another server for network management.

The relations between the logical tool layer and the physical tool layer are visualized by a matrix view (Fig. 3.37). The specialist medical practice only houses three PCs on which the patient management and *MDMS* can be used. The application system is installed on an application server which is hosted by Ernst Jokl Hospital's data center. Both hospitals also host application servers on which the application systems of the respective hospitals are running. For storing data, SANs are used. In the data center of the health care network, there is an application server for the *EHRS* and another server for network management.

**Fig. 3.36** Physical tool layer of CityCare

**Fig. 3.37** Matrix view visualizing "installation" relations between application systems and physical data processing systems

## **3.12 Exercises**

## *3.12.1 Domain Layer: Differences in Hospital Functions*

Look at the functions presented in Sect. 3.3.2. Now imagine a small hospital (e.g., 350 beds) and a large university medical center (e.g., 1500 beds). What are the differences between these hospitals with regard to their functions? Explain your answer.

## *3.12.2 Domain Layer: Different Health care Professional Groups and Health care Facilities*

Look at the functions listed in Sect. 3.3.2. Look at the relationships between the functions and the different health care professional groups (physicians, nurses, administrative staff, others) working in hospitals and medical offces. Select one health care professional group and describe which functions are most important for this group.

## *3.12.3 Domain Layer: The Patient Entity Type*

Look at the entity type "patient" that is interpreted and updated by various functions. Which functions update the patient information, which functions interpret it?

## *3.12.4 Logical Tool Layer: Communication Server*

Imagine a hospital information system that comprises four application systems: a *PAS*, an *MDMS*, a *RIS*, and a *PDMS*. The hospital is now considering the introduction of a communication server to improve data integration. Discuss the short-term and long-term pros and cons of this decision. Which syntactic and semantic standards could be used?

## *3.12.5 Logical Tool Layer: Integration from the User's Point of View*

During a night shift, a nurse uses the *patient administration system* to conduct the administrative *patient admission*. The nurse then uses the *NMDS* to plan nursing care. Now consider the types of integration presented in Sect. 3.8 and discuss how this nurse would recognize a high (or low) level of data integration, semantic integration, user interface integration, context integration, feature integration, and process integration.

## *3.12.6 CityCare*

The following questions can be answered by reading the text and analyzing the 3LGM2 fgures of the CityCare Example 3.11.


## **References**


**Open Access** This chapter is licensed under the terms of the Creative Commons Attribution 4.0 International License (http://creativecommons.org/licenses/by/4.0/), which permits use, sharing, adaptation, distribution and reproduction in any medium or format, as long as you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons license and indicate if changes were made.

The images or other third party material in this chapter are included in the chapter's Creative Commons license, unless indicated otherwise in a credit line to the material. If material is not included in the chapter's Creative Commons license and your intended use is not permitted by statutory regulation or exceeds the permitted use, you will need to obtain permission directly from the copyright holder.

# **Chapter 4 Management Perspective: Scopes and Tasks of Managing Health Information Systems**

In Chap. 3, we discussed the technological perspective of health information systems. We will now examine how health information systems have to be managed so they will fulfll the requirements of the stakeholders as presented in Sect. 1.3.

As already introduced in Sect. 2.12, management of information systems ensures systematic information processing that supports information and knowledge logistics and therefore contributes to the health care setting's goals. High-quality health information systems and their components can only by achieved if the health information systems are systematically planned, monitored, and directed.

Management of information systems can be differentiated into strategic, tactical, and operational management of information systems. In this chapter, we will frst discuss these three scopes of management of information systems and how they are interlinked in more detail. We will then focus in more detail on strategic management of information systems and discuss tasks and methods of strategic planning, strategic monitoring, and strategic directing of health information systems. We will also discuss organizational structures for systematic management of information systems.

Finally, it is important to remember that for the management of information systems we can only say in a few cases what is indeed right and what is wrong. Rather, in practice, decisions must be made again and again as to which solutions and approaches are best suited in the respective setting (Fig. 4.1). In doing so, a balance must be reached between at times conficting goals. This balancing act is what the last section is about.

**Fig. 4.1** Health information systems constitute an essential part of providing good health care. Managing health information systems requires both professional skills and communication

After reading this chapter, you should be able to


Please note that the terms highlighted in italics are terms from the glossary or represent functions or application system types.

## **4.2 Dimensions of Managing Health Information Systems**

In this section, we present in more detail the tasks of managing health information systems in health care facilities. We will discuss strategic, tactical, and operational management, their goals, and their tasks.

As already discussed in Sect. 2.12, *management of information systems* encompasses the management of all components at the three layers of an information system—the management of functions, processes, and entity types, of application components and services, and of physical data processing systems. We consider these components the objects of *management of information systems*.

Although the layers help to structure *management of information systems* by objects, it is helpful to also divide *management of information systems* with regard to its scope into strategic, tactical, and operational management.

*Strategic management of information systems* deals with the information system as a whole and establishes strategies and principles for the evolution of the information system. An important result of strategic management activities is a strategic information management plan.

*Tactical management of information systems* deals with particular functions, application components, or physical data processing systems that are introduced, removed, or changed. Usually, these activities are done in the form of projects. Tactical information management projects are initiated by *strategic management of information systems*. Thus, *strategic management of information systems* is a vital necessity for *tactical management of information systems*. The result of tactical information management projects is an updated information system.

*Operational management of information systems* is responsible for operating the components of the information system. It ensures the smooth operation of the system in accordance with the strategic management of information systems plan. Additionally, operational information management plans, directs, and monitors permanent services for the users of the information system.

Regardless of which objects are currently being processed and on which scope *management of information systems* is currently focused, *management of information systems* is always involved in the tasks of planning, directing, and monitoring.

This results in three dimensions for classifying *management of information systems* as shown in Fig. 4.2. When combining the three scopes, the three main tasks, and the three major objects of *management of information systems*, we can also defne a 3 × 3 × 3 matrix of information management activities.

This separation of activities of *management of information systems* is essential because each of the information management scopes has different perspectives and therefore uses different methods and tools. For example, planning within *strategic management of information systems* focuses on strategic information management plans. Planning within tactical management needs, for example, methods for project management or user requirements analysis, while directing within tactical management needs methods for software development or customizing. Operational management requires methods and tools for topics that range from intra-enterprise marketing of services to service desk and network management.

Strategic, tactical, and operational management depend on each other. Figure 4.3 presents their relationships in a three-layer graph-based metamodel (3LGM2 ) domain layer.

Within *strategic management of information systems*, a strategic information management plan and project portfolios have to be created as a result of planning activities. Strategic planning depends on the business strategy of the enterprise, defned by the strategic enterprise management, on information from HIS quality indicators, and on legal regulations. Since the strategic information management plan contains a project portfolio to be performed in the coming years, strategic directing means initiating these projects. Strategic directing updates a project charter which is then processed by *tactical management of information systems*. Strategic monitoring collects various information regarding the state of the information system components and users' and patients' requirements and compares these with the strategic information management plan and the project portfolio. The resulting HIS quality indicators are fed back to strategic planning.

Within each project of *tactical management of information systems*, the course of the project must be planned (project plan) and the project will be directed and monitored according to this plan. The result of a project are updated information system components. When a project ends, the result is documented in a handover protocol which is passed to *operational management of information systems* for further operation of the information system component.

Executive operational tasks (such as operating a computer server) are not part of information management. Nevertheless, these operational tasks must be planned, directed, and monitored. This is carried out by *operational management of information systems*.

As already indicated in Fig. 4.3, *management of information systems* in health care facilities is performed in an environment full of infuencing factors. Decisions

**Fig. 4.3** 3LGM3 representation of the relationships between functions of "strategic, tactical, and operational management of information systems and related entity types"

made by the strategic enterprise management of the health care facility directly infuence *management of information systems*. For example, the decision of the strategic enterprise management of a health care facility to cooperate in a health care network will have an impact on the future state of the information system. New legal regulations also have an effect on the *management of information systems*. For example, a law enforcing the introduction of a new billing system based on patient grouping will require adaptations in application components. Patients and users, as important stakeholders of an information system, also infuence *management of information systems* with their values, attitudes, and requirements. Patients may demand a patient portal to access some of their data from home, for example. Or *management of information systems* itself may affect the management of the health care facility. If, for example, *management of information systems* proposes the introduction of a multi-professional *electronic health record system (EHRS)*, this must in turn lead to strategic activities such as process reorganization within the health care facility.

Figure 4.4 summarizes these relationships between management and operation of a health information system and the infuencing factors.

We now look at the activities of strategic, tactical, and operational management of information systems in health care facilities.

**Fig. 4.4** Strategic, tactical, and operational management of information systems in health care facilities and their relationships

## **4.3 Strategic Management of Information Systems**

*Strategic management of information systems* deals with the information system of a health care facility as a whole. It depends on and must be aligned to the facility's vision, mission, and strategic goals.

*Strategic management of information systems* and its strategic information management plan are the prerequisites for tactical and operational management of information systems in a health care facility.

We will now discuss in more detail strategic planning, monitoring, and directing of *management of information systems* in health care facilities.

## *4.3.1 Strategic Planning*

Strategic planning is the frst step of a systematic strategic information management process and leads to a strategic information management plan as basis.

Planning, as part of *strategic management of information systems*, must translate vision, mission, and strategic goals into a specifc strategic information management plan. Thus, the most important tasks of strategic planning are *strategic alignment* of business goals and strategic information management goals, and the development of both a long-term *strategic project portfolio* as part of a strategic information management plan and *annual project portfolios*.

#### **4.3.1.1 Strategic Alignment of Business Goals and Information Management Goals**

The basis for *strategic management of information systems* in a health care facility is the mission of the facility. The mission describes what the basic functions of the facility are and what it stands for. For university medical centers in Germany, for example, it is stipulated by law that they must offer the basic functions of *patient care*, medical research, and teaching of future physicians.

Strategic goals are concrete specifcations of how this mission is to be fulflled within a certain, usually longer, period of time. Such goals are set by the management of the facility. The strategic, long-term goals of a health care facility are also called *business goals*. The term "business goal" should not be understood in a purely proft-oriented or economic way, which means focusing on fnancial gain only. Instead, as health care facilities should serve the needs of individual patients and of society, we should understand business goals as all goals of a health care facility that refect its mission in *patient care*, *research*, *and education*.

Health care facilities aim to provide effcient, high-quality health care. They may thus defne, for example, one or more of the following business goals as their strategic, long-term goals:


Different goals and sub-goals result in different information management strategies and different architectures of information systems. Also, advances in information and communication technology (ICT) may infuence business goals. The role of *management of information systems* thus varies between two extremes. At one extreme, *management of information systems* may be seen as a purely supporting function; that is, the business goals determine the information management planning activities. This is called "organizational pull" and the person in charge of *strategic management of information systems* needs to know the business goals of the health care facility. At the other extreme, *management of information systems* is seen as the strategic resource from which the health care facility gains competitive advantage. The application of technological advances mainly determines the further development of the health care facility and its position on the health care market. This is called "technology push." For this, the top management needs to know the potential of information systems with regard to supporting or shaping the business goals. *Strategic management of information systems* must thus be able to offer this information to top management in adequate and understandable form.

Strategic alignment describes the process that balances and harmonizes the business goals of the health care facility and the information management strategies to obtain the best results. Strategic alignment ensures that the strategic information management plan directly supports the business goals and that IT projects and IT budget can be directly tied to these business goals.

#### **4.3.1.2 Strategic Information Management Plan**

The *strategic information management plan* represents the long-term planning of the information system of a health care facility. This plan describes the business goals, the information management goals, the current state of the information system, the future state of the information system, and the steps to transform the current into the planned information system. *Strategic management of information systems* must create and regularly update this plan. The strategic information management plan is the basis for all tactical and operational information management activities and is the precondition for systematically directing and monitoring the information system of a health care facility.

*Strategic management of information systems* is an ongoing process, and there is no use in trying to solve all problems of information processing at the same time. Solely a stepwise approach, based on different levels of priorities, is feasible. The strategic information management plan is therefore the basis for a *strategic project portfolio* that describes projects or groups of projects, their priority, and a rough timeline for their initiation for the coming years.

The long-term strategic information management plan is usually valid for a longer period of time (e.g., 3–5 years). However, requirements (e.g., due to legal changes or new user requests) and resources (staff, money) may change more quickly than the strategic information management plan, or strategic monitoring results may require a faster adjustment or an update of prioritization of projects. This is refected in the annual project portfolio (Sect. 4.3.1.3) that is annually derived from the strategic project portfolio. It lists the projects to be executed in the next year.

The strategic information management plan should be written by the persons responsible for *strategic management of information systems* (e.g., the chief information offcer (CIO)) and approved by the top management. Without proper strategic planning, it would be a matter of chance if the information system of a health care facility fulflled strategic information goals. But considerable efforts have to be made for creating strategic plans.

Figure 4.5 presents an overall view on strategic information management planning and use.

In larger health care facilities, several stakeholders are typically involved in the creation, updating, approval, and use of strategic plans, such as top management, clinical and administrative departments, service departments and information management departments, staff members, funding institutions, consultants, or hardware and software vendors.

These stakeholders may have different expectations of a strategic plan and are involved in different lifecycle phases for the following strategic plans:


**Fig. 4.5** Strategic information management planning of health care facilities. A "strategic information management plan" gives directives for the construction and development of an information system. It describes the recent and the intended information system's architecture

Usually, the CIO, supported by the information management department, creates and maintains a proposal for the strategic information management plan. The CIO is interested in having clearly defned requirements for *management of information systems*. Top management is interested in the seamless and cost-effective operation of the health care facility. Top management approves the plans (probably together with the funding institutions). Employee representatives should be involved in eliciting the requirements, as they will be using the resulting information systems. The current strategic plan will be used by the information management departments and the vendors of components when modifying the information system. External consultants may help to create the plan though they may also be engaged in negotiations for the approval of the plan.

The most essential purpose of a strategic information management plan is to improve the information system so that it can best contribute to the business goals of the health care facility. This purpose should determine the structure of strategic plans; that is, it should show a path from the current situation to an improved situation in which the business goals are achieved as far as possible and reasonable.

A strategic information management plan thus should encompass the business goals, the resulting information management goals, the current state of the information system, and an assessment of how well the current information system fts the goals. Based on this assessment, the future state of the information system is described, together with a migration path represented by a strategic project portfolio that allows this future state to be reached.

The strategic plan must also deal with the resources needed to realize the planned architecture and must include rules for the operation of the information system and a description of appropriate organizational structures. Examples of resources are money, personnel, software and hardware, rooms for servers and (paper-based) archives, and rooms for staff training. The resources should ft the architecture and vice versa.

The general structure of strategic information management plans is described in the following paragraphs and is summarized in Fig. 4.6. It should be noted that this is only a basic structure which may be adapted to the specifc requirements of a health care facility.


**Fig. 4.6** Structure of a strategic information management plan


A short management summary and appendices describing the organizational structure, personnel resources, the building structure, etc. are likely to complement a strategic plan. Section 4.8.1 presents as example the structure of the strategic information management plan of Ploetzberg Hospital.

#### **4.3.1.3 Annual Project Portfolio**

The *annual project portfolio* is derived from the strategic project portfolio as described in the strategic information management plan. While the strategic project portfolio represents the planned projects for a longer period of time (e.g., 3–5 years), the annual project portfolio describes the projects to be executed in the next year.

The annual project portfolio thus contains a list of projects to be initiated in the next year together with their priorities, timeline, and rough resources. This annual project portfolio implements the long-term strategic project planning into an annual planning. It may refect changes in prioritization of projects due to internal or external changes in the health care facility (e.g., a new data protection law or the availability of a new mobile technology). The annual project portfolio must be approved by top management, which also provides the needed resources for all projects.

An important instrument for building, managing, and updating annual project portfolios is portfolio management. Originating in the feld of fnance, the term portfolio management is today used in different management contexts.

A portfolio is a collection of objects grouped together to facilitate effective management of activities to meet strategic business objectives. Managing a portfolio comprises the selection and management of objects based on their value for the health care facility, but also based on their costs and risks and on their dependencies (i.e., one project can only start when another project has ended). Portfolio management establishes categories of objects (i.e., projects or application components) and defnes priorities for each category (i.e., which projects should start frst). Each category carries a different degree of risk and may thus need different project management methods.

In the context of *management of information systems*, portfolio management can focus on projects of information management or on components such as application components or physical data processing systems.

Project portfolio management categorizes IT projects, among other things, according to their contribution to the business goals, their risks, and their expected costs. Based on prioritizing projects, project portfolio management allows for the planning and controlling of IT projects. A project portfolio is typically built when an organization defnes or refreshes its strategic goals and its strategic information management plan. Both the fnal strategic project portfolio and the derived annual portfolio need to be authorized by the top management. To build a project portfolio, the following steps can be followed [1]:


Unlike project portfolio management, application component portfolio management considers different types of components. For example, the portfolio proposed by the Gartner Group distinguishes three categories of application components: Utility applications are application components that are essential for the operation of the health care facility but have no infuence on the business success and, therefore, are independent of the business goals (e.g., the *patient administration system*). Enhancement applications are application components that improve the performance and thus contribute to the success of a health care facility (e.g., computerbased *nursing management and documentation system (NMDS)*). Frontier applications are application components that infuence the position of the health care facility in the health care market (e.g., telemedical applications). Information management planning should aim at a well-balanced application portfolio—on the one hand, to effciently support essential functions of the health care facility and, on the other hand, to not miss out on future technological innovations.

## *4.3.2 Strategic Monitoring*

After having planned the information system strategically, one may expect that the information system will operate well in most of its functions, in most of its information processing tools, and in most parts of its operating organization. In many cases, however, problems may occur. Confdentiality of data may not be assured in some circumstances; transmission of clinical reports may not be timely; adequate data integration capabilities may not be provided and thus consistency of redundant data may not be assured between application components; or, since there is no data warehouse, the health care facility may not be able to collect and analyze aggregated data to support *patient care* and operations. There may be additional problems to be taken into account at a strategic level. For example, users may be increasingly dissatisfed with a specifc application component, technical or motivational problems may lead to a decrease in documentation quality, increased documentation time may limit the time available for direct *patient care*, there may be an unforeseen amount of high effort for support and training, or the number of medical errors may rise due to software errors or unusable software.

Besides low software quality, badly organized projects in tactical *management of information systems* or errors in *strategic management of information systems* may also lead to the problems described above. Such problems may become apparent very slowly, for example, when a formerly "good" component is not updated to match the overall technical progress, leading to inacceptable performance and functionality, or when more and more new application components need to be integrated into a spaghetti-styled architecture (compare Sect. 3.6.4). But problems may also arise very suddenly, for example, when a server suddenly crashes and no replacement is available or when, due to a software error, a wrong fnding is presented to a patient, a physician makes a wrong decision, and the patient is harmed.

Monitoring, as part of *strategic management of information systems*, means continuously auditing quality and cost of the information system and assessing whether the strategic information management plan has been implemented as intended. Auditing determines whether the information system is able to fulfll its tasks effciently, i.e., whether it contributes signifcantly to the facility's vision and mission, meets the stakeholders' requirements (Sect. 1.3), and fulflls the relevant laws. To allow auditing, monitoring needs to receive information from *tactical management of information systems* (e.g., on the successful completion of projects) and from operational management (e.g., on number of service desk calls) as well as information from users (e.g., from user satisfaction surveys) and from strategic management of the health care facility (e.g., on changes in the vision and mission). Additional information on the quality of the information system can be gained through evaluation projects. Monitoring results are used as input to direct tasks of *management of information systems*, which could, for example, initiate further projects. Monitoring results will also give feedback to update the strategic information management plan, which could, for example, lead to further activities of strategic management.

Typically, strategic monitoring comprises activities such as permanent monitoring activities, *benchmarking*, and ad hoc monitoring. These are explained in more detail in the following sections.

#### **4.3.2.1 Permanent Monitoring Activities by Key Performance Indicators (KPI)**

An information system of a health care facility is typically too complex to allow all its components to be monitored at the same time. However, it is useful to defne a subset of quality criteria that is to be monitored on a regular (daily, weekly, monthly, yearly) basis. Quantitative measurements for regular monitoring of the achievement of strategic goals are also called *key performance indicators* (*KPIs*). In general, KPIs are a set of quantitative and well-defned performance measurements that demonstrate how effectively an organization is achieving key objectives. KPIs not only allow areas of improvement to be identifed but also help to compare own achievements to similar organizations (benchmarking).

KPIs for information systems demonstrate how effectively key objectives of the information system, as typically defned in the strategic information management plan, are reached. These KPIs could comprise, for example:


In Chap. 5, we will further discuss indicators for the quality of an information system and how they can be structured.

These KPIs should be recorded in quantitative and, as far as possible, in automated form to allow monitoring on a regular basis. Example 4.8.2 presents some KPIs of the information system of Ploetzberg Hospital.

Besides monitoring those indicators, data from other sources can also be related to the quality of the information system and thus be of interest for *management of information systems* as well, such as data from patient satisfaction surveys, medical error reports, or commentary on the health care facility in the local press. In addition, national legislation (e.g., new data protection law) and standardization initiatives (e.g., new version of HL7) should be monitored, as both may affect the information system.

Sudden changes in monitored numbers can indicate problems (e.g., malfunctioning of a component), which could then initiate more detailed analysis and corrections that are then to be initiated by strategic directing.

Permanent monitoring activities can be used to identify areas of improvement, but they can also be used to compare the quality of the information system with other organizations or with established standards in the form of benchmarking. Some benchmarking approaches are presented in the following section.

#### **4.3.2.2 Benchmarking of Health Information Systems**

*Benchmarking* in general describes a process in which organizations evaluate various aspects of their performance and compare it to given standards or to the best organizations ("best practice"). Benchmarking uses quantitative criteria (KPIs) for comparing situations.

In strategic management, benchmarking is seen as an important approach to assess the performance of a health care facility. Benchmarking is often seen as part of a continuous quality improvement process in which health care facilities measure and then steadily improve their performance.

In strategic management of the information system of a health care facility, benchmarking can be used to assess the quality and costs of the information system in comparison with the information system of comparable facilities. Often, regional groups of health care facilities join together on an ad hoc basis to defne and compare benchmarking criteria.

The Digital Maturity Self-Assessment [2], for example, measures how well secondary care providers in England use digital technology to achieve a health and care system that is paper-free at the point of care. The assessment measures digital maturity against the following three key themes: readiness, meaning the extent to which health care facilities are able to plan and deploy digital services (e.g., strategic alignment and fnancing of IT); capabilities, meaning the extent to which health care facilities are using digital technology to support the delivery of care (e.g., IT use to support functions such as order management or decision support); and infrastructure, meaning the extent to which health care facilities have the underlying infrastructure in place to support these capabilities. These three key themes are selfassessed using a set of questions. Results can be easily compared between health care facilities to highlight opportunities for improvement or support investment decisions.

#### **4.3.2.3 Ad hoc Monitoring Activities by Evaluation Projects**

Ad hoc monitoring activities may be initiated after larger changes of a component (e.g., introduction of a new application component) have been performed or when sudden larger problems have been observed. Ad hoc activities help to analyze a certain situation in detail in order to better understand the reasons of an observed problem or the consequences of a larger change. These ad hoc activities are conducted in the form of evaluation studies that are planned and conducted as evaluation projects by *tactical management of information systems* [3].

For example, during and after the introduction of a *computerized physician order entry system (CPOE)*, its quality and its effects on clinical care could be analyzed using a selection of the following evaluation questions:


Typically, quantitative and qualitative methods can be combined to answer such evaluation questions. Monitoring, as part of *strategic management of information systems*, collects and reports the evaluation results to directly give feedback to strategic planning of the information system.

We will discuss planning and conducting evaluation projects in more detail in Sect. 5.4.

## *4.3.3 Strategic Directing*

Strategic directing of information systems is a consequence of planning and monitoring the functions and the architecture of the information systems and the organization of *management of information systems*.

Directing, as part of *strategic management of information systems*, means transforming the strategic information management plan into action, i.e., systematically updating the information system to make it conform to the strategic plan. The system's manipulation is usually done by the initiation of projects. The projects deal with the construction or further development of components of the information system.

The projects to be initiated are taken from the strategic project portfolio as established in the strategic information management plan. The decision to initiate certain projects is part of strategic information planning. Strategic directing is then responsible for their prioritization, coordination, and initiation. Planning, directing, and monitoring these projects are the tasks of *tactical management of information systems*. Operational management will then be responsible for the proper operation of the components. An example of strategic directing is the initiation of a project for the introduction of the *CPOE system*.

In detail, the following main tasks of strategic directing can be identifed:


## **4.4 Tactical Management of Information Systems**

*Tactical management of information systems* deals with specifc components at the information system's three layers. It aims to introduce, remove, change, or maintain those components. Activities of *tactical management of information systems* are usually performed within projects. *Projects* are unique undertakings that are characterized by objectives, by restrictions with regard to available time and resources, and by a specifc project organization. Projects have to be initiated as part of an information strategy, which is formulated in the strategic project portfolio of the strategic information management plan. The result of all tactical information management projects is an updated information system [4].

Examples of projects of *tactical management of information systems* are:


Planning, as part of *tactical management of information systems*, means planning projects and all the resources needed for them. Even though tactical information management projects are based on the strategic information management plan, they each need an individual project plan. This project plan describes the project's scope and motivation, the problems to be solved, the goals to be achieved, the tasks to be performed, the activities to be undertaken to reach the goals, and the resources needed to complete the project.

Directing, as part of tactical management, means the execution of such tactical information management projects based on their project plan. Therefore, directing includes typical tasks of project management such as execution of the planned

**Fig. 4.7** Typical phases of tactical information management projects

working packages, resource allocation and coordination, and reporting of the project's results.

Monitoring, as part of tactical management, means continually checking whether the initiated project is running as planned and whether it will produce the expected results. Monitoring results may infuence project planning, as a project's plan may be updated or changed according to the results of the project's monitoring in a given situation.

Typically, tactical information management projects comprise a planning phase (including project initiation and planning), an execution phase (which is about monitoring the project and one or more of the following activities: system analysis and assessment, system specifcation, system selection, system introduction, and system evaluation), and a completion phase (Fig. 4.7).

## **4.5 Operational Management of Information Systems**

*Operational management of information systems* is responsible for operating the components of the information system. It ensures their smooth operation in accordance with the strategic information management plan of the health care setting.

Planning, as part of *operational management of information systems*, means planning organizational structures, procedures, and resources (e.g., fnances, staff, rooms, or buildings) that are necessary to ensure the faultless operation of all components of the information system. For example, *operational management of information systems* may require the installation of a user service desk and a service support system that enables the quick transmission of users' error notes to the responsible services. Such systems, but also respective staff resources, need to be planned and be made available for a longer period. Therefore, they should be allocated based on the strategic information management plan. Moreover, planning in this context concerns the allocation of personnel resources on a day-to-day basis (e.g., planning of shifts for staff responsible for user support or network management).

To guarantee the continuous operation of the most important *components of an information system*, it is helpful to draw up a long-term plan for *operational management of information systems*. Such a concept should clarify which components have to be supported, who is responsible for the operational support, and what the intensity of operational support should be. Table 4.1 presents components, responsibilities, tasks, and the intensity that should be defned as part of the operational management concept for the computer-based part of an information system.

As an example, a concept for operational management in a health care facility could clarify:


**Table 4.1** Dimensions to be considered for *operational management of information systems* of the computer-based part of an information system

#### 4.5 Operational Management of Information Systems


Directing, as part of *operational management of information systems*, is the sum of all management activities that are necessary to implement the plan and to ensure proper responses to operating problems of components of the information system. This comprises, for example, providing backup facilities, operating a service desk, maintaining servers, and keeping task forces available to repair network components, servers, PCs, or printers. Directing in this context deals with engaging the resources planned in such a way that faultless operation of the information system is ensured.

Monitoring, as part of *operational management of information systems*, deals with monitoring the proper working and effectiveness of components of the information system. For example, a network monitoring system may continuously be used to monitor the availability and correct working of network components of the health care facility.

Typically, three levels of operational support can be distinguished. First-level support is the frst address for all user groups with any kind of incidents disrupting the desired operating fow. It may consist, for example, of a central 24-hour hotline (service desk) responsible for frst trouble shooting and the management of user accounts, or it may consist of decentralized information managing staff. When solutions cannot be found for the reported incidents during frst-level support, secondlevel support must take over. This is performed by specially trained informatics staff, often located in the central information management department, who are usually responsible for the operation of the specifc application components. The third-level support, fnally, addresses the most severe problems that cannot be solved by the second-level support. It can be performed, for example, by specialists from the software vendor.

Operation and maintenance of components of the information system are part of its *operational management*. However, if problems occur (e.g., frequent user complaints about a *medical documentation and management system (MDMS)*), appropriate projects may be executed by *tactical management of information systems* (e.g., introducing a better version of the documentation system).

Built on top of *strategic and tactical management of information systems*, *operational management* thus offers users comprehensive services. These services go beyond simply delivering hardware and software. Rather, they are designed to help users use these components in a way that is helpful for their professional work. Such services are also known as *IT services*. Thus, the information management department of a health care facility is an IT service provider that delivers IT services to its customers, the users of the facility's information system. The management activities that serve to provide quality IT services are grouped under the term *Information Technology Service Management* (ITSM). ITSM therefore has the task to design, provide, deliver, and improve such customer-centered services. The Information Technology Infrastructure Library (ITIL) [5] is the de facto standard framework for ITSM. ITIL was developed for the British government in order to defne best practices for all governmental data centers.

For *operational management of information systems*, ITIL recommends setting up the following processes in particular:

The incident management process deals with the handling of incidents that disrupt users in the completion of their work (e.g., a non-functioning application system or printer). The aforementioned service desk is used to receive complaints about such incidents. If a solution for the customer cannot be found there immediately, the incident is declared a problem and passed on to the problem management process. If the problem management process reveals that changes need to be made to the components directly affected by the incident or to other components of the information system, the change management process will handle this. Since both small and large changes can always have side effects, ITIL also recommends a change management board as part of the process to coordinate and monitor the required changes. Incident, problem, and change management all require confguration management. With this term, ITIL means the processes that ensure that *management of information systems* always has a correct overview of all components of the information system and their connections, i.e., the information system's confguration. Corresponding confguration management systems can be based on 3LGM2 and the three levels defned there (Sect. 2.14).

Especially in a health care facility, where human lives may depend on the proper operation of the information system, it is recommended to have a systematic ITSM and to follow ITIL.

## **4.6 Organizational Structures for the Management of Health Information Systems**

Organizational structures for *management of information systems* differ greatly among health care facilities. In general, for each facility the adequate organization for strategic, tactical, and operational management of information systems and its proper integration into the decision structures of the facility must be established by *IT governance* as mentioned before. The resulting structures will depend on the facility's size, internal organization, needs, and goals.

Organizational structures can be described at the level of the health care facility as a whole (e.g., a chief information offcer, a central information management department) and at the departmental level (e.g., specifc information management staff for a certain department, a certain outpatient unit). We will now look at the role of the CIO and the information management department in more detail.

In this section, we frst discuss IT governance and the decision-making processes before discussing important roles in this context: the CIO, the *Information Management Board*, and the Information Management Department.

## *4.6.1 IT Governance and Organizational Structures for Information Management*

IT governance is the part of the overall management of a health care facility that deals with the organizational structures for decision-making in *management of information systems* [6]. The decision-making structures must be defned in such a way that the *management of information systems* is well integrated with the facility's management and is aligned to its strategic goals.

The organizational structures for decision-making must enable the *management of information systems* to create value for stakeholders (compare Sect. 1.3 for a list of stakeholders and their requirements) and minimize risks related to the information systems. Simply said, IT governance focuses on which organizational structures are needed to achieve value from the information system, and *management of information systems* describes how to use the structures for creating this value by properly planning, directing, and monitoring the information system.

In order to fnd the right organizational structures for decision-making for a health care facility, one should frst be clear about the felds in information management where decisions need to be made. In strategic information management, these are, in particular, decisions on the planned state of the facility's information system as part of the creation of the strategic information management plan. This includes decisions on the application systems to be used (Sect. 3.4), the architectural style to be used (Sect. 3.6), the design of the IT infrastructure (Sect. 2.11), and the basic IT principles that should be followed. IT principles refer, for example, to the use of certain standards (Sect. 3.7.2). In addition, there are the decisions on the migration path and the associated strategic project portfolio (Sect. 4.3.1.2). Of particular importance are the fnancial decisions about the amount of investment in the information system and the allocation of the (limited) budget among the projects in the portfolio. In tactical information management, decisions must be made within the projects about the project plan and repeatedly about the appropriate execution of the individual project steps. In operational information management, decisions must be made repeatedly, especially about the prioritization of daily tasks.

Decisions in these decision-making felds can be made in different constellations depending on the circumstances of the health care facility and the management culture customary there. The types of such constellations described in the literature include business and IT monarchies as well as feudal and federal structures. In the monarchical constellations, the decision on the information system is made by the top management of the facility or by the information management leadership. Advisory bodies are often used to prepare the decisions. In feudal constellations, decisions are delegated to the management of sub-departments, such as the medical departments. In federal constellations, decisions on the information system tend to be made collegially by bodies such as an information management board (Sect. 4.6.3). Federal constellations are particularly common in large institutions or even corporate groups, as they are most likely to take into account both local characteristics and the interests of various stakeholders. Anarchic situations can also be observed, in particular in large institutions, though they may be desirable, for example in academia as a way of promoting creativity.

A framework for implementing IT governance principles in companies is COBIT (Control Objectives for Information and Related Technology) which is published by the Information Systems Audit and Control Association (ISACA). COBIT defnes goals both for the governance and the *management of information systems*. Furthermore, it describes processes and best practices that must be implemented in a company in order to achieve value creation through the information system and information. COBIT is being continuously developed and is currently available in version COBIT 2019 [7].

Depending on the decision-making feld (see above), the decision-making constellations in the same facility may well vary. Regardless of the decision-making constellations chosen, two structures are indispensable: the CIO and the information management department he or she is in charge of.

## *4.6.2 Chief Information Offcer (CIO)*

It is generally useful to centralize responsibilities for the *management of information systems* in one role. In larger health care facilities such as hospitals, this role is usually called *chief information offcer* (*CIO*) . Other common designations include vice president (or director) of information systems, of information services, of *management of information systems*, of ICT, or of information resources.

The CIO bears overall responsibility for the strategic, tactical, and operational management of the information system and the budgetary responsibility and has authority over all employees concerned with management of the information system. The specifc position of the CIO demands dedicated medical informatics competencies, executive and managerial competencies, and economic competencies.

Depending on the size of the health care facility, the role and the tasks of a CIO may be performed by one dedicated person (e.g., a full-time medical informatics specialist) or may be covered by another high-ranking role within the top management (e.g., by the chief executive offcer (CEO)).

Sometimes, the role of CIO is supported or replaced by more specifc roles such as the chief medical information offcer (CMIO) and the chief nursing information offcer (CNIO), each responsible for the related clinical aspects of information management.

If the institution has an information management board (Sect. 4.6.3), it is usually chaired by the CIO. Conversely, the leader of such a board is often considered the CIO if the position of CIO has not been explicitly established.

Ideally, the CIO should report directly to the top management of the health care facility and, therefore, should be ranked rather high in the organizational hierarchy. For example, the CIO may be chair of the information management department and in this role directly report to the CEO.

The CIO's role should be a strategic one that comprises the following tasks of strategic management of the information system:


The CIO's close relation to or, in some cases, even the membership within the top management team should provide the possibility to infuence the vision and mission of the health care facility using IT as a strategic resource. Therefore, both business and medical knowledge and the ability to effectively communicate with other managers, for example, the chief fnancial offcer (CFO) or the nursing director, is important for a CIO.

In some cases, the CIO may focus more on tactical and even operational management of the information system than on its strategic management. This may depend on the size and internal organization of the health care facility, such as top management membership, internal communication networks among top executives and the CIO, top management's strategic knowledge about the strategic role of the information system, and the personality of the CIO.

## *4.6.3 Information Management Board (IT Steering Committee)*

As explained in Sect. 4.6.1, in federal decision-making structures, strategic decisions on the information system tend to be made collegially by bodies such as an *information management board*. Members of this board are typically high-level representatives from the top management and from the main departments of a health care facility (see Sect. 4.8.3 for an example). Such a board is often referred to as the IT Steering Committee.

If the institution has an information management board, it is usually chaired by the CIO. Conversely, the leader of such a board is often considered the CIO if the position of CIO has not been explicitly established.

An information management board is particularly common in large institutions or even corporate groups, as they are most likely to take into account both local characteristics and the interests of various stakeholders.

## *4.6.4 Information Management Department*

In larger health care facilities, there is usually one central information management department (often called the department for medical informatics, data center, or ICT department). This department handles the facility's strategic management of the information system and at least of the tactical and operational information management of those parts of the information system with facility-wide relevance (e.g., the *enterprise resource planning system (ERPS)*, the *medical documentation and management system (MDMS)*, and the computer network).

In larger health care facilities, the information management department may consist of units that are responsible for certain tasks (e.g., different units for incident management, project management, clinical systems, administrative systems, IT networks, or medical devices). If the information management department also handles the strategic management of the information system, the head of this department can be considered the CIO.

With regard to the responsibilities for tactical and operational management of the information system, it is sometimes not useful and often not feasible to totally centralize these services. Especially in larger health care facilities, the services are performed in cooperation between central units and the decentralized staff. This staff may be comprised of dedicated medical informaticians or especially skilled users. These local information managers have responsibilities for tactical and operational management of the information system with regard to their own department but in accordance with the central information management department. For example, they may (with support from the central unit) introduce a facility-wide application component in their department and operate it. On the other hand, they will also have

to handle additional information needs of their departments, for example, by introducing a dedicated departmental system. However, this should be done only in accordance with the strategic information management plan.

In Sect. 4.8.3, we present as an example the organizational structure of information management of Ploetzberg Hospital.

## **4.7 Balance as a Challenge for the Management of Health Information Systems**

After reading the previous sections, it may seem that *management of information systems* must merely defne strategic goals for *management of information systems*, aligned with the business goals of the health care facility, and work towards them. However, reality is not that simple. *Management of information systems* is a lot about balancing priorities between various and often conficting goals. We will now discuss fve aspects of this task of "balancing" priorities.

## *4.7.1 Balance of Homogeneity and Heterogeneity*

The collection of information processing tools (both on the logical and at the physical tool layer) should be as homogeneous (i.e., comparable in appearance and usability, for example, using tools from the same vendor) as possible and as heterogeneous as necessary. In general, a homogeneous set of information processing tools makes training and support of users easier and thus leads to reduced costs for the health information system. However, in reality, we usually fnd a very heterogeneous set of tools at both the logical and the physical tool layer. Why?

In any health care facility, we need application systems at the logical tool layer for the support of the functions. Maximum homogeneity, at least for the computerbased part of a health information system, can easily be reached by a (DB1 , AC1 , V1 ) architecture, when just one application system exists that is implemented through a single application software product from a single manufacturer. Usually, however, diverse application software products from different manufacturers have to be purchased, which can lead to very heterogeneous (DBn , ACn , Vn ) architectures. These products might please the various stakeholders of the health care facility (which will all have optimal support for their tasks), but they will make integration, operation, and user support much more diffcult. These diffculties are often overlooked by the stakeholders concerned. In this situation, it is the task of the *management of information systems* to ensure and support an appropriate compromise between the need for economical homogeneous information processing and the needs of the various stakeholders.

At the physical tool layer, heterogeneity is often the consequence of the evolution of the health information system, comprising different generations of computer systems. This could be prevented only if all components are completely exchanged regularly, which is generally not sensible. In addition, heterogeneity is not always bad. For example, different mobile tools (laptops, tablets, and smartphones) may be needed to best support different user needs in different situations. But again, when this heterogeneity of information processing tools is not systematically managed, it can lead to the uncontrolled proliferation of tools and to unnecessary costs.

The better all stakeholders are involved in *strategic management of information systems* through an appropriate organization, the more this situation can be avoided.

## *4.7.2 Balance of Computer-Based and Paper-Based Tools*

It is the task of managing health information systems to manage information processing in such a way that the strategic goals of the health care facility can best be reached. For a health care facility whose goal it is to provide very personal and humane treatment, it might therefore make sense to abstain from the use of technology and especially computers for all immediate physician–patient contact. This would include, for example, writing with paper and pen (or with the so-called digital pens) during a direct physician–patient encounter, rather than using a computer for data entry, as this may help support this strategic goal.

For a health care facility whose goal involves technological leadership and integrated processes, it might be more appropriate to proceed in the opposite direction, i.e., to strive for a good support of all working processes through computerbased tools.

That is, the optimum of computer support is not defned by the maximum; rather, it evolves through the strategic goals of the health care facility and its stakeholders as well as through the functions to be supported.

## *4.7.3 Balance of Data Security and Working Processes*

The data stored in a health information system are worth protecting. Patients must be confdent that their data will not be made available to an unauthorized third party. To ensure this, the appropriate laws of the particular country are to be adhered to. However, health information systems are not just purely technical, but rather are socio-technical systems. This means that people are also part of the information system and are therefore also responsible for data security and protection.

A health information system should implement strict access control methods to ensure that unauthorized access is impossible. However, this can lead to hindrances in the daily work of the health care professionals. For example, it may occur that a medication cannot be prescribed in an emergency when the attending physician belongs to another hospital department and therefore does not have the right to read the lab result or to order a medication. This can, in an extreme case, even lead to a life-threatening situation. Thus, an access control system that is strict and adapted to predefned tasks and roles in a department can hinder the cooperation between health care professionals and other departments. This would be unfortunate, as it is the job of the *management of information systems* to build the health information system in such a way that cooperation is supported. Consequently, following a thorough risk analysis, it should be weighed whether access control measures in certain situations should be less strict for medical staff, thereby strengthening their own level of responsibility.

Similar risks should be considered in determining how long data should be kept. Health care laws, research needs, and lawsuit requirements should be addressed. So, for example, following the expiration of the storage period, if documents are destroyed, it could be diffcult to prove that the hospital carried out a correct medical process in the event of a lawsuit. The resulting consequences would be requests for damage compensation and possibly punishment. However, long-term storage of data may be costly and space-consuming (e.g., archive room, disk storage capacity). Risk management must be carried out with strong support from the health care facility's management.

## *4.7.4 Balance of Functional Leanness and Functional Redundancy*

*Functional leanness* describes a situation where one function is supported by one and only one application component. The opposite is functional redundancy where a specifc function is supported by more than one application components. For example, imagine a health care facility where two different *NMDS* are in use, one in the surgical units, and the other in the other units. In this case, central functions such as nursing care planning are supported by two application systems. This situation will result in additional costs both for investment, maintenance, training, and support. But as discussed with controlled data redundancy, functional redundancy is not always bad and may best support the specifc needs of the users in the different areas.

Functional redundancy may also be found between different types of application systems. For example, *patient admission* may be supported by application systems other than the *patient administration system* to allow easy *patient admission* during nighttime, for example, in a radiology department, by using the *radiology information system (RIS)*. This situation may be suitable, as it will provide a more convenient and well-known tool in the diagnostic area and a faster and more sophisticated tool in the patient administration unit. However, clear organizational rules and interfaces between both application systems are needed to achieve data integration and to avoid double documentation or transcription.

Thus, it is the management's task to check carefully where and why there is functional redundancy because unmanaged functional redundancy may lead to disruptions of work processes, confusion of users, and unnecessary costs. If needed, application systems or functions within application systems need to be removed to increase functional leanness.

## *4.7.5 Balance of Documentation Quality and Documentation Efforts*

Documentation of clinical data is needed for many purposes, such as for information exchange within the health care team, for clinical decision-making, for clinical research, for reimbursement issues, for hospital controlling, and for legal statistics. Consequently, many groups inside and outside the hospital proft from a complete, accurate, and timely clinical documentation.

On the other hand, high-quality documentation takes time. Physicians and nurses may feel that the time needed for documentation reduces the time they have for *patient care*. The feeling is especially strong in facilities where documentation is not well supported by existing tools and documentation processes. Insuffcient organization of documentation may lead to documentation that is more time-consuming than necessary, to double documentation of the same data, and to transcriptions and media breaks. This all reduces the motivation for documentation and may lead to the feeling that documentation is not helpful but a burden. This in turn may reduce the quality of the documented data. This fact is especially relevant if data items need to be documented by staff that will not use this data for their own purposes. Due to the integrated nature of the processes within a hospital, this is rather common.

*Management of information systems* must therefore carefully balance the amount of documentation that is really needed for the various purposes and the effort that health care professionals have to invest. Well-designed documentation forms, high level of standardization, integrated documentation tools, and a systematic planning of documentation help to reduce effort and to increase the awareness that documentation is an important and indeed useful part of clinical practice.

## **4.8 Examples**

## *4.8.1 Strategic Information Management Plan of Ploetzberg Hospital*

Table 4.2 presents the structure of the strategic information management plan of Ploetzberg Hospital.

**Table 4.2** Structure of the strategic information management plan (2022–2026) of Ploetzberg Hospital


7. Conclusion

## *4.8.2 Health Information System Key Performance Indicators (KPIs) of Ploetzberg Hospital*

The CIO of Ploetzberg Hospital annually reports to the hospital's management about the amount, quality, and costs of information processing of the Ploetzberg Hospital information system. For this report, the CIO uses health information system KPIs that have been agreed on by a regional group of hospital CIOs (Table 4.3). Each year, the hospitals exchange and discuss their reports as part of a best practice benchmark with other hospitals—this comparison is not shown in the table.


**Table 4.3** Extract from the Ploetzberg Hospital health information system's benchmarking report 2024. *KPI* key performance indicator

## *4.8.3 Organization of the Management of the Ploetzberg Hospital Information System*

Figure 4.8 presents the organization of management of the information system of Ploetzberg Hospital. The CIO here is Mrs. Garzia. She is head of the information management department and also chair of the information management board. In both positions, she is responsible for strategic, tactical, and operational management of the information system at the hospital. The operational management of the information system is partly supported by local information managers (e.g., technical specialists or medical informaticians) in dedicated department such as the radiology or the cardiology.

Mrs. Garzia directly reports to Mrs. Johns, the CEO of Ploetzberg Hospital. Recently, both discussed the strategic information management plan that is just being updated. The discussions focused on the question whether the strategic

**Fig. 4.8** Extract from the organizational structure of the management of the information system at Ploetzberg Hospital

information management plan is fully aligned with the general business goals of Ploetzberg Hospital. As CEO, Mrs. Johns will present and approve the strategic information management plan in the next meeting of the top management.

The draft of the strategic information management plan was developed by Mrs. Garzia. It already has been discussed and confrmed by the information management board. This board includes a representative from top management (e.g., the director or nursing) as well as the deputy head physicians of the radiology department, Mr. Hess, and of the cardiology department, Mrs. Smyrek. The board supported Mrs. Garzia in aligning the strategic information management plan with the needs and requirements of the clinical departments.

## **4.9 Exercises**

## *4.9.1 Activities of Managing Information Systems*

In Sect. 4.2, we introduced a three-dimensional classifcation of activities of management of information systems (Fig. 4.2). How would you describe the scope and tasks of the following activities of managing information systems?


## *4.9.2 Strategic Alignment of Hospital Goals and Information Management Goals*

Imagine you are the CIO of a hospital in which almost no computer-based tools are used. One of the hospital's goals is to support health care professionals in their daily tasks by offering up-to-date patient information at their workplace.

Which main goals for *management of information systems* could you defne based on this information? Which functions should be prioritized to be supported by new application systems? What could a strategic project portfolio and a migration plan for the next 5 years look like?

## *4.9.3 Structure of a Strategic Information Management Plan*

In Sect. 4.8.1, we presented the structure of the strategic information management plan of Ploetzberg Hospital. Compare its structure to the general structure presented in Sect. 4.3.1.2, consisting of strategic goals, description of current state, assessment of current state, future state, and migration path. Where can you fnd this general structure in Ploetzberg Hospital's plan?

## *4.9.4 An Information-Processing Monitoring Report*

Look at the health information system's KPIs of Ploetzberg Hospital in Example 4.8.2. Try to fgure out some of these numbers for a real hospital and compare both hospitals' KPIs in the form of a benchmarking report. It may help to look at the strategic information management plan of this hospital or at its website.

## *4.9.5 Relevant Key Performance Indicators (KPIs)*

Imagine you are the CIO and have to select the three most relevant indicators for the quality of your information system at your hospital: Which would you select? You can look at the examples in Sect. 4.8.2 to get ideas. Explain your choice.

## *4.9.6 Organizing User Feedback*

You are asked to organize regular (e.g., every half year) quantitative user feedback on the general user satisfaction with major clinical application components of your hospital as part of health information system's monitoring. Which user groups would you consider? How could you gather user feedback regularly in an automatic way? Explain your choice.

## *4.9.7 Information Systems Managers as Architects*

Information systems managers can be partly compared to architects. Read the following statement and discuss similarities and differences between information system architects and building architects [8]:

"We are architects. […] We have designed numerous buildings, used by many people. […] We know what users want. We know their complaints: buildings that get in the way of the things they want to do. […] We also know the users' joy of relaxing, working, learning, buying, manufacturing, and worshipping in buildings which were designed with love and care as well as function in mind. […] We are committed to the belief that buildings can help people to do their jobs or may impede them and that good buildings bring joy as well as effciency."

## **References**


**Open Access** This chapter is licensed under the terms of the Creative Commons Attribution 4.0 International License (http://creativecommons.org/licenses/by/4.0/), which permits use, sharing, adaptation, distribution and reproduction in any medium or format, as long as you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons license and indicate if changes were made.

The images or other third party material in this chapter are included in the chapter's Creative Commons license, unless indicated otherwise in a credit line to the material. If material is not included in the chapter's Creative Commons license and your intended use is not permitted by statutory regulation or exceeds the permitted use, you will need to obtain permission directly from the copyright holder.

# **Chapter 5 Quality of Health Information Systems**

## **5.1 Introduction**

The International Organization for Standardization (ISO) defnes quality in general as the ability to meet all the expectations of the purchaser of goods or services or, in other words, as the degree to which a set of inherent characteristics fulflls requirements, where "requirements" means needs or expectations.

In Sect. 1.3, we already discussed the requirements of various stakeholder groups and their expectations on the information system. In this chapter, we will now discuss in more detail the various aspects of the quality of a health information system. Assessing the quality of health information systems using quality characteristics, and maintaining this quality, is one of the tasks of managing information systems (Fig. 5.1).

After reading this chapter, you should be able to


**Fig. 5.1** Health information systems constitute an essential part of providing good health care. Consultant physician reviews data on a ward

## **5.2 Quality of Management of Information Systems**

In Chap. 4, we discussed the tasks of strategic, tactical, and operational management of information systems and the related organizational structures of information management. We also introduced IT governance and Information Technology Service Management (ITSM). We will now use a top-down structure when discussing the quality of *management of information systems*, starting with the quality of IT governance and fnishing with the quality of ITSM.

## *5.2.1 Quality of IT Governance*

IT governance is part of the overall management of a health care facility. It aims at providing appropriate organizational structures for managing the information system in such a way that it creates value for stakeholders.

To assess the quality of IT governance, we can assess the following aspects:

IT governance structures should be established that enable the *management of information systems* to create value for stakeholders and minimize risks related to the information systems (Sect. 4.6.1). For example, responsibilities for strategic,

tactical, and operational management need to be clearly assigned to organizational units (such as the Information Management Department, Sect. 4.6.3) or roles (such as the chief information offcer (CIO), Sect. 4.6.2). IT governance should be based on established best practice frameworks and standards, such as COBIT (Control Objectives for Information and Related Technology). COBIT is an international framework for IT governance that defnes a set of generic processes for the management of IT in an organization for each of these processes. COBIT defnes objectives, key activities, inputs and outputs, and performance measures. Processes defned by COBIT [1] include managing the strategic information management plan, managing project portfolios, IT risk management, IT change management, ITSM, or IT operation.

In addition, enough resources should be provided for IT staff, IT infrastructures, and application components so that the information system can best meet the business demands. For example, the annual IT budget should be suffciently high to hire qualifed staff to manage the information system.

Finally, the health information system should be operated in such a way that all information management laws of the specifc country are fulflled. Different laws must be fulflled in every country, such as laws regarding data protection, data interchange, IT security, or health statistics. These laws must be taken into account by *management of information systems*.

## *5.2.2 Quality of Strategic Management of Information Systems*

Strategic management of the information system deals with the information processing of a health care facility as a whole. It depends on the facility's business goals and must translate these into an appropriate strategic information management plan.

To assess the quality of *strategic management of information systems*, we can look at the following aspects:

First, a strategic information management plan should exist and should be updated regularly. It should be closely and visibly aligned with the business strategy and business goals of a health care facility. This means that the outcome of managing information systems, i.e., the information system itself, should clearly support the business goals of the health care facility. For example, the resulting health information system should support business goals such as high-quality care of chronically ill patients, participation in cross-institutional clinical research, or attracting patients from neighboring regions.

In other words, information logistics should be possible in a way that it supports all intended business processes and functions and fulflls the need of the various stakeholder groups (physicians, nurses, management, patients and their relatives, researchers, etc.). We already discussed the requirements of the various stakeholders in Sect. 1.3. If *management of information systems* is to be considered successful, then the information system should fulfll the requirements of these stakeholder groups. The strategic information management plan should thus be developed with input from major stakeholder groups within the health care facility. Details on how to develop a strategic information management plan were explained in Sect. 4.3.1.2.

This also means the IT project portfolio (Sect. 4.3.1) should be effectively managed in a way that maximizes the intended value to the health care facility and to the stakeholders. For example, projects that deliver the most business value (e.g., the introduction of a *picture archiving and communication system (PACS)* to support faster and better diagnosis and treatment) may be prioritized among other projects (e.g., a website for clinical staff informing on most recent business news) depending on the business goals.

Strategic monitoring should be done based on clearly defned key performance indicators (KPIs) and use data from several sources (e.g., user surveys, analysis of hotline calls). Evaluation projects should be conducted to assess the quality of certain parts of the information system. For example, after the introduction of a new *computerized provider order entry (CPOE) system*, changes in medication errors should be analyzed systematically. Details on how to plan and conduct evaluation projects are discussed in Sect. 5.4.

*IT risk management* should continuously assess risks and liabilities of information management. This includes the continuous identifcation, assessment, mitigation, monitoring, and management of risks related to IT. For example, an IT risk analysis may show that the whole hospital operation depends on the functioning of the communication server and of the IT network, and thus activities will be started to reduce the risk of network failures by increasing redundancy of technical components.

Finally, the architecture of the information system should be documented in an up-to-date way. It is surprising how many health care facilities do not have a consistent and clear description of their application components, the functions they support, and the interfaces between them. Establishing and using such an architectural description is an important activity within strategic information management planning. Using the three-layer graph-based metamodel (3LGM2 ) been described in Sect. 2.14 is helpful.

## *5.2.3 Quality of Tactical Management of Information Systems*

*Tactical management of information systems* deals with particular functions, application components, or physical data processing systems. It aims to introduce, remove, change, or maintain components of the information system.

There are some ways to assess the quality of *tactical management of information systems*:

Projects of *tactical management of information systems* should be derived from the annual project portfolio. They should be conducted using best practices and state-of-the-art methods in project management in all project phases: project initiation, project planning, project execution, and project completion (Sect. 4.4).

All projects should be fnalized within the planned time frame and within the planned budget. Changes in time frame and budget must be justifed and approved by *strategic management of information systems*. Finally, and most importantly, projects should be successful, i.e., they should reach the intended project goals.

As part of *tactical management of information systems*, certifcation may also play a role. *Certifcation* in general means confrming that an object or organization has certain characteristics. Certifcation of health information systems in general describes a process where an accredited body confrms that the information system of a health care facility fulflls certain quality characteristics that have been predefned by an external organization. Examples of certifcation are provided in Example 5.5.3. Vendors may try to obtain these certifcates for their *application software products* to obtain an advantage in the market. Health care facilities may check for the availability of these certifcates when buying software for a new application component. In general, certifcation increases transparency of different products and fosters buyers' knowledge about products, as certifcation organizations often compile information about the different products and technologies. Increased transparency and knowledge in turn have a positive impact on the buyers' willingness to invest in new technology. Even when a certifcation does not guarantee that a component is good regarding all and every criterion, certifcation may contribute to an increased transparency of quality of health information systems in general.

## *5.2.4 Quality of Operational Management of Information Systems*

*Operational management of information systems* is responsible for operating the components of the information system. It ensures its smooth operation in accordance with the strategic information management plan of the health care facility.

To assess the quality of *operational management of information systems*, we can assess several aspects.

First, we can assess whether the operation of the components of the information system (such as server, clients, networks, interfaces) runs smoothly and without frequent or longer interruption.

To minimize risks, a business continuity plan should be available that describes how the information system can continue to support the functions even in a case of larger failures or disasters (e.g., when the central server room of a health care facility is destroyed).

As part of IT governance, there should be a clear responsibility with documented tasks and processes for operating the physical data processing systems and the application systems in a health care facility.

*Operational management of information systems* should be based on established best practice frameworks and standards such as COBIT [1] as a framework for IT governance (Sect. 5.2.1) or Information Technology Infrastructure Library (ITIL) [2] for ITSM (Sect. 4.5).

ITSM provides a perspective on *management of information systems* that focuses on how IT is provided to serve the needs of customers. We can consider the management of IT services as that part of *operational management of information systems* focusing on responding to the customer's needs. The term "IT service" in a health facility comprises the application systems (e.g., *LIS* or *PACS*) and the physical data processing tools (e.g., ward computers, mobile computers) discussed in Sects. 3.4 and 3.10. However, it also comprises more specifc IT services such as remote VPN (virtual private network) access to the network of the health care facility, specifc application interfaces, antivirus shielding, or videoconferencing facilities. All these are IT services that are needed by customers (e.g., by the clinical departments or the administration of a health care facility).

The desired content and quality of IT services should be clearly defned in *servicelevel agreements (SLAs)*. An SLA describes, among other things, the processes supported by the IT service (e.g., access to images via a *PACS*), the desired outcome for the customer (e.g., mobile access to all patient images is possible for a physician), planned service times (e.g., 24/7), availability target (e.g., 99% availability of image access), allowed downtimes (only during night), number of users (e.g., 350 physicians), required levels of support (e.g., on-site support during day, remote support during night), and responsibilities (including duties of the service provider, duties of the customer, duties of the service user). An SLA is a contract regarding the provision of an IT service, for example, between a department and the IT department.

An IT service desk, also called helpdesk, should be available where users can report any incidents related to IT services and get help. The quality of the IT services should be continuously monitored and improved. All incidents related to IT services should be systematically documented, their root causes should be analyzed, and ways to prevent future problems should be developed and implemented.

Finally, IT staff should be suffciently trained and competent to operate physical data processing systems and the computer-based applications.

## **5.3 Quality of Architectures and Infrastructures**

In the previous section, we discussed the quality of the *management of information systems*. The outcome of high-quality information management is, hopefully, a high-quality information system. We will now discuss how we can assess the quality of the information system.

## *5.3.1 Quality at the Domain Layer*

The overarching objective of a health information system is to support the functions of a health care facility. In Sect. 3.3, we presented these functions in more detail, such as *patient identifcation*, *decision-making and patient information*, *execution of diagnostic, therapeutic, and nursing procedures*, or billing.

Health information systems should suffciently support information and knowledge logistics (Sect. 2.7) within *patient care*, administration, and management. To achieve a high quality of the information and knowledge logistics at the domain layer, information logistics should be as good as possible given the resources used. Good information and knowledge logistics comprises the following aspects:


In addition, the domain layer describes the data to be processed and provided. To assess the quality of the data at the domain layer, we can assess the following data quality aspects:


## *5.3.2 Quality at the Logical Tool Layer*

The information system quality at the logical tool layer comprises the quality of application components and the quality of their integration.

The following criteria help to assess the quality of an application component:


The general architecture of the health information system should be suffciently fexible to adapt to the changing needs of the hospital. For example, it should be easy to add new application systems to the information system, and application components should be easily replaceable by other (more advanced) application components. A star-based architecture (CP1 architecture) with a communication server (Sect. 3.9.2) and application components offering standardized interfaces support the exchange or addition of application systems.

An architecture can be called "saturated" if as many functions as possible are supported by computer-based tools and if there are no or only a small number of

non-computer-based tools still in use. Please note that computer-support is not a goal in itself. However, a mix of paper-based and computer-based tools within a function often leads to defciencies in information logistics such as transcriptions. Transcription means the manual transfer of data from one application component to another, for example, manually entering patient diagnoses from the *patient administration system* in the *CPOE system* or scanning a discharge letter to add it to the electronic patient record (EPR). Transcriptions are time-consuming and may lead to data errors. Therefore, transcriptions have to be avoided by using standardized interfaces between application components.

To achieve integration in "best-of-breed" architectures (ACn , Vn ), application components need to share and store the same data. Data redundancy is thus unavoidable. For example, patient administrative data are stored in the *patient administration system*, the *RIS*, and the *LIS*. This data redundancy needs to be closely managed to provide consistent data. Approaches for handling data redundancy through integration technologies were presented in Sect. 3.9.

## *5.3.3 Quality at the Physical Tool Layer*

The information system quality at the physical tool layer comprises the quality of physical data processing systems and their integration.

The quality of physical data processing systems can be described by several characteristics:


At the physical tool layer, redundancy is often valuable to reduce risks of system failure. For example, data may be stored redundantly in different areas in order to avoid data loss in case of fre. Or data may be duplicated on different hard discs in a specifc database server (e.g., using redundant array of independent discs (RAID) technology), allowing reconstruction of data when a hard disc fails. Thus, technical redundancy is also an important quality criterion for the physical tool layer.

## *5.3.4 Quality of Integration*

In Chap. 2, we learned that health information systems are constructs built from a variety of components. In Sect. 3.7, we discussed that these components, especially application systems, need to be interoperable so they can be integrated to best support functions and business processes. Integrating application systems, as we saw in Sect. 3.8, can be done in a number of ways, each achieving specifc qualities of the information system. We will therefore summarize these types of integration here again as quality criteria for health information systems.

Data integration is achieved in a health information system when data that have been recorded in different application components once are available wherever they are needed without having to be reentered (Sect. 3.8.1). Consequently, in a health information system where data integration is given, data can be brought together for analysis wherever it is needed. Moreover, if the data needs to be updated, this only has to be done in one place, even if the data are redundantly stored in several application systems. Overall, data integration is the frst and quite basic quality characteristic within heterogeneous health information systems, as it allows application systems to exchange and reuse data while preserving data integrity.

Semantic integration (Sect. 3.8.2) is guaranteed if different application systems use the same system of concepts, i.e., they interpret data the same way. Semantic integration is an important quality characteristic within heterogeneous health information systems, as it supports the exchange of meaningful information between application systems.

User interface integration (Sect. 3.8.2) is guaranteed when different application components represent data and organize their user interfaces in a unifed way. User interface integration supports the usability of application systems and reduces errors when searching for or entering data. It thus also contributes to data quality and patient safety, making it an important quality characteristic within heterogeneous health information systems, as it supports ease-of-use and reduces usage errors of graphical user interfaces.

Context integration (Sect. 3.8.4) is an important quality characteristic within heterogeneous health information systems, as it allows synchronizing and coordinating context among application systems. It thus allows application systems to automatically follow patient, user, and other contexts and thus supports the user when working with several application systems. Note that context integration stands on its own. It neither contributes to data, to semantic, or to user interface integration. Vice versa, these types of integration will not support achieving context integration.

Feature integration (Sect. 3.8.5) means that features are not implemented redundantly in multiple application systems. Feature integration thus reduces costs for both implementation and maintenance of application systems. Overall, feature integration is an important quality characteristic within heterogeneous health information systems, as it allows sharing of functions among application systems.

An integrated health information system should support the business processes effectively. From this perspective, process integration (Sect. 3.8.6) is indeed the overall vision of integration within heterogeneous information systems. Process integration is guaranteed when business processes are effectively supported by a set of interacting application systems. Systematic adoption of Integrating the Health care Enterprise (IHE) profles is an indicator for structural quality on which smooth process integration can be achieved. Process integration is an important quality characteristic within heterogeneous health information systems, as it describes a situation where different application systems interoperate in an optimal way so that business processes are best supported.

## **5.4 Evaluating the Quality of Health Information Systems**

Evaluation can be defned as the act of measuring or exploring components of a health information system. The result of an evaluation should provide information to support decisions concerning the health information systems, such as decisions regarding optimizing, replacing, or further deploying a component.

This defnition of evaluation highlights the fact that evaluation can comprise both quantitative ("measuring") as well as qualitative ("exploring") aspects and that evaluation should answer a clear question and thus support management decisions of strategic or tactical management of information systems. Evaluation studies can, for example, help to justify IT investments, to verify that the information system is effective and safe, or to understand problems and to improve the information system.

We will now discuss the basic phases of an evaluation study. We will see how to identify an evaluation question together with stakeholders, how to collect quantitative and qualitative data, and fnally how to answer the evaluation question and how to use the evaluation results to improve the health information system. We will provide only a short introduction to this topic. Please consult specifc textbooks to learn more about health IT evaluation (such as [3]).

## *5.4.1 Identifying the Evaluation Question*

Evaluation studies of components of health information systems should answer a clear question and thus inform a decision. Such a decision may focus on ways to improve a component or the need to replace a component by another one. Identifying an evaluation question that is useful in a given situation is thus the frst crucial step for any evaluation.

Which evaluation question is useful depends on the context and especially on the adoption phase of the component. Adoption can be described as the successful integration of an innovation in a health care facility. Adoption is a time-dependent process.

The Clinical Adoption Metamodel [4] describes four dimensions of adoption of application systems that depend on each other: The frst dimension of adoption is "availability," which comprises the ability of users to access the system, the availability of the system, and the availability of content and features of the system. The second dimension of adoption is "system use," comprising the actual use of the system and the subjective user experience with the system. The third dimension of adoption focuses on "clinical behaviors" and comprises the meaningful adaptation of clinical processes to the system. The fourth dimension of adoption is reached when the new system has an impact on "clinical outcome" at the patient level, the provider level, or the population level. Combined, these four dimensions describe an adoption trajectory from frst implementation of a new application system (or a specifc feature of it) to changes in outcomes.

This adoption model is helpful to identify the evaluation questions that are most relevant for given situation. In other words: Depending on the state of adoption of an application system, only specifc evaluation questions are of relevance and make sense. For example, imagine that a health care facility has introduced a *CPOE system* for medication ordering with the aim to increase effciency and quality of prescriptions.


Evaluation questions thus have to be properly chosen depending on the adoption phase of an application component and depending on the decision that is to be supported by the evaluation, such as decision on further rollout, on further upgrades or other technical improvements before rollout, or on cancellation of a pilot project.

Given the usual constraints of time and money, an evaluation should focus on a limited set of evaluation questions and not try to answer too many questions. To increase the chance that evaluation focuses on an evaluation question that is useful to decision-makers, the decision-maker needs to be consulted when defning the evaluation question.

Identifcation of the most relevant evaluation questions can be done, for example, in a workshop with the decision-maker, where the following questions could be discussed:


Such a workshop between the CIO, the medical director, and the evaluator, for example, could show that the *CPOE system* is already well adopted in one pilot department. It is now important to better understand the effect of the *CPOE system* on medication errors and patient outcome to be able to decide on further rollout. The major evaluation question will therefore be: "Does the *CPOE system* improve medication safety?"

After defning the evaluation questions, clear indicators need to be defned. For example, medication safety may be measured by counting prescription errors or adverse drug events or by looking at length of stay or mortality. Which indicator is best to answer a given evaluation question needs to be carefully decided based on the context, the available data, and the available scientifc literature.

## *5.4.2 Deciding on the Study Design*

Depending on the study question and considering the context of the study (e.g., available resources), the study design needs to be carefully chosen. Several types of study designs exist:

First, we have to decide whether the study is planned as a quantitative study, a qualitative study, or a mixed-method study. Quantitative studies focus on collecting quantitative data (e.g., number of patient safety incidents or number of user logins) to answer the study question, while qualitative studies collect qualitative data (e.g., free text comments within surveys or user comments from interviews). Mixedmethod studies combine quantitative and qualitative data.

Second, we have to decide whether to conduct an exploratory study, a descriptive study, or an explanatory study. Explorative studies try to explore and describe a given situation, which means generating information to improve understanding of the situation. For example, an explorative study may try to fnd out the reasons for higher medication errors after introduction of a *CPOE system*. Explorative studies are typically qualitative or mixed-method studies (i.e., they often apply open-ended observations or interviews). Descriptive studies focus on measuring a predefned attribute in a group of objects. For example, a descriptive study may measure user acceptance of *CPOE systems* or IT knowledge of the hospital staff. Descriptive studies are typically quantitative studies (i.e., they often apply a standardized survey or standardized observations). Finally, explanatory studies try to assess predefned hypotheses. For example, an explanatory study may test the hypothesis that introducing a *CPOE system* signifcantly reduces medication errors in a given clinical setting. Explanatory studies are typically quantitative studies (i.e., they use quantitative measures to determine changes of the effect).

Third, in case an explanatory study is planned, we have to decide whether to conduct it as an experimental study, a quasi-experimental study, or a nonexperimental study. For experimental trials, the randomized controlled trial (RCT) is considered the gold standard with highest internal validity. By conducting an RCT, we can determine with a certain probability whether a given intervention (e.g., a *CPOE system*) led to a certain effect (e.g., a reduction of medication errors). Quasi-experimental study designs also try to assess a relationship between an intervention and an effect but have less internal validity compared to RCTs. Quasiexperimental designs are, for example, before-after trials or trials with a non-randomized control group. Both experimental trials and quasi-experimental trials are also called intervention studies, as they comprise a predefned intervention. Non-experimental studies (also called observational studies) also try to assess the relationship between an intervention and effect, but they do not intervene in any way, instead observing and collecting available (quantitative) data. They can be performed as cross-sectional studies (i.e., collecting data only at one point in time) or as longitudinal studies (i.e., collecting data at several points in time, for example, every 3 months).

Fourth, we have to decide whether to conduct a laboratory study or a feld study. In laboratory studies, we can better control the overall study setting, yet the external validity, i.e., the transferability of results to real settings, is limited. In feld studies, it is more diffcult to control the overall study settings, but external validity is higher.

## *5.4.3 Collecting Quantitative Data*

Quantitative data comprise data that can be described by numbers. Numbers can easily be statistically analyzed, aggregated, and compared. The basic idea of quantitative evaluation methods is that objects have attributes (such as duration or amount) that can be exactly measured. To obtain data representative for a predefned population, a sampling is selected and then analyzed.

Typical quantitative evaluation methods comprise time measurements, quantitative observations, or quantitative surveys.

Time measurements comprise time-motion analyses or work-sampling studies. The time-motion analysis is based on trained observers that measure the duration of observed events (e.g., tasks) while using a predefned list of event categories. Typically, for time-motion analysis, one observer is needed for each observed actor (e.g., user), which is quite resource-intensive. This disadvantage is resolved by the work sampling analysis. Here, trained observers document which task is being executed only at predefned (e.g., every 5 min) or randomly selected time intervals. This allows them to observe several actors in parallel. By counting the number of observed tasks in each category, the overall distribution and thus the duration of each task can be calculated. To obtain precise numbers, however, this requires a relatively large number of observations to be done. Please note that both approaches (time-motion and work sampling) are typically conducted by trained external observers, though they can in principle also be conducted by the actors (e.g., users) themselves—this, however, may limit the quality of the data.

Quantitative observations comprise observations of clinical situations or processes or the analysis of available data (e.g., log fles) in which the number of events that occur in a given time period is counted by an observer. This can, for example, involve counting medication errors (based on an analysis of patient records), counting the number of clicks when using certain software, counting the number of physician–patient interactions, or counting the number of patients entering a department. As for any measurement, special attention should be given to training the observers and to using standardized observation protocols to achieve inter-observer reliability.

Quantitative surveys use standardized, closed questions that lead to quantitative results. For questionnaires addressing subjective opinions and feelings, the 5-point Likert scale is often used ("strongly agree"—"agree"—"neither agree nor disagree"—"disagree"—"strongly disagree"). The quality of data achieved by questionnaires depends on a thorough formulation of questions and predefned answer categories. Each questionnaire should be pretested. The available literature should thus be consulted before planning a questionnaire in order to ensure objectivity, reliability, and validity of results. If possible, available and validated questionnaires should be reused.

## *5.4.4 Collecting Qualitative Data*

Qualitative data comprises text and any other non-numerical data. Qualitative data can describe individual situations and contexts in quite some detail. Typical qualitative evaluation methods comprise qualitative interviews, qualitative observations, or qualitative content analysis.

Qualitative interviews comprise all forms of semi- or unstructured interviews that use open questions, thus generating free text as a result. This allows the respondent to answer freely and allows interaction between interviewer and respondent. The interview can be conducted with one or more respondent at the same time. Group interviews support interaction between respondents but should only be done in groups without hierarchical dependencies. In any case, a pretested interview instruction is needed that describes how the interviewer should conduct the interview and document the results. Answers are typically recorded by tape and later transcribed in verbatim or aggregated protocols. The data can be analyzed using qualitative content analysis, for example.

Qualitative observations comprise open, less-standardized, non-quantitative observations of processes or events. Contrary to quantitative observations, the aim is not to count and measure, but to obtain deeper insight into a situation. The observations are typically documented in a feld diary or on predefned observation protocols. Qualitative observations generate text (such as observer notes) that can be analyzed using qualitative content analysis. Please note that for qualitative observation, there should be a certain familiarity of the observer with the observed feld (e.g., with the situation in the clinical department).

Qualitative content analysis is used to analyze text that obtained from qualitative interviews or qualitative observations. Qualitative content analysis is a methodological, planned approach for grouping qualitative data into categories. Here, the material is analyzed stepwise and coded into several available categories. The categories can either be defned beforehand (deductive approach), developed while reading and analyzing the text (inductive approach), or defned beforehand and refned while analyzing the text (mixed approach). The coding of text into categories should be reproducible; it must therefore be clearly documented and explained with the so-called anchor examples. Typically, the text material is read and coded more than once to make sure that nothing is overlooked and that the categories are homogeneous and all flled with text examples. Based on the categories and the text passages that are related to them, the text can then be further analyzed to identify larger patterns and to answer the study questions.

## *5.4.5 Answering the Evaluation Questions*

If an evaluation was carefully planned, the collected quantitative and qualitative data should now allow the previously defned evaluation question to be answered. For example, a pre-post study of prescription errors showed that prescription errors were largely reduced by the *CPOE system.* This result motivates further rollouts.

Evaluation results may help to improve the quality of the information system, for example, the quality of integration (Sect. 5.3). Evaluation studies that aim mostly at collecting data to improve an information system are also called formative evaluation studies. Formative evaluation studies often take place in early phases of adoption. For example, a typical formative evaluation assesses whether users are using a *CPOE system* as intended by conducting qualitative observations to identify if there is need for further user training. Results of formative evaluation will thus help to decide on needs for improvement in technology, processes, or training.

Evaluation results may also answer the question whether the application system has achieved its intended goals. These evaluations typically focus on a certain outcome of a component and take place in later adoption phases. These types of evaluation studies are also called summative evaluation studies. For example, a typical

summative evaluation assesses whether the *CPOE system* has improved medication safety after 1 year of using the *CPOE system* by applying quantitative chart analysis. The results of summative evaluation will help to justify the expenses of the *CPOE system* and motivate further rollout.

## **5.5 Examples**

## *5.5.1 Unintended Effects of a Computerized Physician Order Entry Nearly Hard-Stop Alert*

The introduction of application systems may have unintended effects. The careful evaluation of impact and unintended effects of application systems is thus an important task of management of information systems. We will now have a look at an example of an evaluation study that showed some unintended effects of CPOE systems.

Table 5.1 presents the abstract of an RCT on automatic alerts in a *CPOE system*. The authors analyzed whether the so-called hard-stop alert can reduce unwanted drug–drug interactions. Such a "hard-stop alerts" appears on the screen to alert the physician about potential problems associated with a particular prescription and blocks the clinician's order from further execution to avert potentially serious reactions.

**Table 5.1** Abstract from "Unintended Effects of a Computerized Physician Order Entry Nearly Hard-Stop Alert" [5]

Background: The effectiveness of *CPOE systems* has been modest, largely because clinicians frequently override electronic alerts

Methods: To evaluate the effectiveness of a nearly "hard-stop" *CPOE system* prescribing alert intended to reduce concomitant orders for warfarin and trimethoprim-sulfamethoxazole, a randomized clinical trial was conducted at two academic medical centers in Philadelphia, Pennsylvania. A total of 1981 clinicians were assigned to either an intervention group receiving a nearly hard-stop alert or a control group receiving the standard practice. The study duration was August 9, 2006, through February 13, 2007

Results: The proportion of desired responses (i.e., not reordering the alert-triggering drug within 10 min of fring) was 57.2% (111 of 194 hard-stop alerts) in the intervention group and 13.5% (20 of 148) in the control group (adjusted odds ratio, 0.12; 95% confdence interval, 0.045– 0.33). However, the study was terminated early because of four unintended consequences identifed among patients in the intervention group: a delay of treatment with trimethoprimsulfamethoxazole in two patients and a delay of treatment with warfarin in another two patients

Conclusions: An electronic hard-stop alert as part of an inpatient *CPOE system* seemed to be extremely effective in changing prescribing habits. However, this intervention precipitated clinically important treatment delays in four patients who needed immediate drug therapy. These results illustrate the importance of formal evaluation and monitoring for unintended consequences of programmatic interventions intended to improve prescribing habits

The study was designed as a quantitative, explanatory feld study that was conducted as an RCT. The study found that these alerts can help to reduce the number of alert-triggering orders. But it also found that the hard-stop alert led to clinically important treatment delays in four patients.

## *5.5.2 Clinical Decision Support for Worker Health: A Five-Site Qualitative Needs Assessment in Primary Care Setting*

Besides evaluating the effect of an intervention, evaluation may also try to understand reasons for successful or unsuccessful implementation of an application system. For these kinds of questions, qualitative studies are often chosen.

Table 5.2 presents the abstract of such a qualitative study. The authors analyzed need, barriers, and facilitators for clinical decision support (CDS) in primary care. The study was performed as a qualitative, exploratory feld study.

The authors found several factors that may hinder or foster the use of CDS in primary care. The results of this multi-center study can now be used to implement CDS in commercial application software products for primary care.

**Table 5.2** Abstract from "Clinical Decision Support for Worker Health: A Five-Site Qualitative Needs Assessment in Primary Care Settings." [6]

Background: Although patients who work and have related health issues are usually frst seen in primary care, providers in these settings do not routinely ask questions about work. Guidelines to help manage such patients are rarely used in primary care. *Electronic health record systems (EHRS)* with worker health CDS tools have potential for assisting these practices

Objective: This study aimed to identify the need for and barriers and facilitators related to implementation of CDS tools for the clinical management of working patients in a variety of primary care settings

Methods: We used a qualitative design that included analysis of interview transcripts and observational feld notes from 10 clinics in fve organizations

Results: We interviewed 83 providers, staff members, managers, informatics and IT experts, and leaders and spent 35 h observing. We identifed eight themes in four categories related to CDS for worker health (operational issues, usefulness of proposed CDS, effort and time-related issues, and topic-specifc issues). These categories were classifed as facilitators or barriers to the use of the CDS tools. Facilitators related to operational issues include current technical feasibility and new work patterns associated with the coordinated care model. Facilitators concerning usefulness include users' need for awareness and evidence-based tools, appropriateness of the proposed CDS for their patients, and the benefts of population health data. Barriers that are effort-related include the additional time the proposed CDS might take as well as other pressing organizational priorities. Barriers that are topic-specifc include sensitive issues related to health and work and the complexities of information about work

Conclusion: We discovered several themes not previously described that can guide future CDS development: technical feasibility of the proposed CDS within a commercial electronic health record (EHR), the sensitive nature of some CDS content, and the need to assist the entire health care team in managing worker health

## *5.5.3 Certifcation of Health Information Systems*

There exist several national and international approaches for certifcation of application software products to be used in health care, such as the European CE certifcation, the German digital health application (DiGA) repository, the ONC Health IT Certifcation Program in the U.S. and IHE Connectathons.

CE certifcation is mandatory in the European Union for all application software products developed to be used for medical purposes such as diagnosis, *prevention*, monitoring, or prognosis. For example, a software calculating the correct amount of insulin needed is considered a medical device and thus needs CE certifcation. CE certifcation assures that the software complies with all European legal requirements regarding safety, health, and environment. Depending on the risk class that the application software product belongs to, certifcation can be done by the manufacturer of the software or it must be done through external auditing. Details on CE certifcation are available in the EU's Medical Device Regulation 2017/745 [7].

The German DiGA repository for "health applications" [8] is maintained by the Federal Institute for Drugs and Medical Devices and lists health apps that fulfll a set of quality requirements. Besides being CE-certifed as a medical device of a lowrisk class, the application must be actively used both by the patient and by a health care provider and must fulfll certain data protection and information safety requirements. In addition, the vendor must provide supporting evidence (e.g., from evaluation studies) about the positive effect of the health application on the quality of *patient care*. When listed in the DiGa repository, health applications can be prescribed by a physician and are reimbursed by the patient's health insurance company.

In the United States, the Health IT Certifcation Program is operated by the Offce of the National Coordinator for Health Information Technology (ONC) [9]. To be certifed, a vendor of a component must fulfll a number of requirements that assess whether an application software product supports clinical processes, care coordination, privacy and security, patient engagement, and exchange and interoperability of patient data. Part of certifcation is the annual testing of the component in real-world settings.

The IHE initiative [10] (Sects. 3.7.2.5 and 3.7.2.6) strives to increase interoperability between components based on existing standards such as HL7 and DICOM (Digital Imaging and Communications in Medicine). IHE offers testing for the standards-based interoperability between components in the so-called Connectathons. During a Connectathon, components of different vendors exchange information with other components in a supervised environment. The Connectathon provides detailed validation of the components' interoperability and compliance with IHE profles. The results of testing are published by IHE.

Besides certifcation of quality and interoperability of software, health care facilities or vendors can strive for certifcation of the quality of their internal processes by applying for ISO certifcations or for the Joint Commission certifcation.

The ISO 9001 standard [11] defnes criteria for the *quality management system* of an organization. An ISO 9001 certifcate states that an organization follows certain formalized quality processes, that it monitors the outcome of its processes, and that it facilitates their continuous improvement.

The ISO 27001 standard [12] focuses on information security management. An ISO 27001 certifcate states that an organization has an established information security management system and is able to manage the security of information, such as employee information, patient information, or fnancial information.

The Joint Commission [13] is a US-based organization assessing health care organizations and programs based on preestablished quality standards. A subset of its standards focuses on *management of information systems* and addresses issues such as data privacy, information security, standardization of data collection, and interoperability of data.

## **5.6 Exercises**

## *5.6.1 Quality of Integration*

Read the following case descriptions and discuss the integration problems using the types of integration presented in Sect. 5.3.4. Which negative effects for information logistics result from the identifed integration problems?


## *5.6.2 Data Collection in Evaluation Studies*

Read Examples 5.5.1 and 5.5.2 and determine which methods for collecting data (as described in Sects. 5.4.3 and 5.4.4) have been used.

## *5.6.3 Study Design in Evaluation Studies*

Read Examples 5.5.1 and 5.5.2 and describe the chosen study design in more detail, using the description presented in Sect. 5.4.2.

Try to explain for which types of study questions the RCT is the best study design.

## **References**


**Open Access** This chapter is licensed under the terms of the Creative Commons Attribution 4.0 International License (http://creativecommons.org/licenses/by/4.0/), which permits use, sharing, adaptation, distribution and reproduction in any medium or format, as long as you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons license and indicate if changes were made.

The images or other third party material in this chapter are included in the chapter's Creative Commons license, unless indicated otherwise in a credit line to the material. If material is not included in the chapter's Creative Commons license and your intended use is not permitted by statutory regulation or exceeds the permitted use, you will need to obtain permission directly from the copyright holder.

# **Chapter 6 Information Systems for Specifc Health Care and Research Settings**

## **6.1 Introduction**

In Chaps. 3 and 4, we introduced health information systems and two perspectives when dealing with them: the technological perspective and the management perspective. Using the technological perspective, we describe the architecture and integration of an information system. Using the management perspective, we describe the strategic, tactical, and operational management of an information system.

In this chapter, we will now refer to these perspectives with respect to specifc health care settings. Please recall Chap. 1 where life situations and their relative share of health care were introduced. The following institutional health care settings were mentioned in particular:


Each health care setting thus has a specifc role in providing health care and is related to specifc life situations. This specifc role corresponds to specifc structures, processes, and stakeholder groups in these different health care settings. Not surprisingly, the information systems of these health care settings also show typical differences both from a technological and from a management perspective that we want to explore further in this chapter.

Besides discussing information systems in these institutional health care settings, we will also address information systems for medical research facilities as well as transinstitutional information systems in regions or in states. We will also discuss how personal environments such as homes can be considered for health care (Fig. 6.1).

For most of these health care settings, you will frst be introduced to their characteristics, such as their activities, areas, and persons. Then we will describe their specifc technological and management perspectives, building on Chaps. 3 and 4.

As mentioned in Chap. 1, health care organizations can vary from country to country. Therefore, the characteristics described here, as well as their technological and management perspectives, may also differ to some extent from country to country.

Please also recall the defnitions of "information system" and "health information system" in Chap. 2 with respect to specifc health care settings. Let us take hospitals as an example of such health care settings: Hospital information systems are the socio-technical subsystem of hospitals, which comprise all data, information, and knowledge processing as well as the associated human or technical actors in their respective data, information, and knowledge processing roles. The same holds accordingly for other health care settings mentioned in this chapter.

After reading this chapter, you should be able to

**Fig. 6.1** Health information systems constitute an essential part of providing good health care. Patient with shoulder pain trains at home with an autonomous rehabilitation system

#### 6.2 Information Systems in Hospitals


Please note that the terms highlighted in italics are terms from the glossary or represent functions or application system types.

## **6.2 Information Systems in Hospitals**

## *6.2.1 Characteristics of Hospitals*

Hospitals are settings where patients with acute and chronic diseases or in an emergency situation receive inpatient and, partially, outpatient treatment.

Areas of hospitals to be considered by hospital information systems are wards, outpatient units, service units (e.g., diagnostic units such as laboratory and radiology departments, therapeutic units such as the operation room, and other units such as pharmacy, patient records archive, library, blood bank), hospital administration areas (e.g., patient administration department, department of quality management, fnancial and controlling department, department of facility management, information management department, general administration department, human resources department), offces, and writing services for (clinical) report writing. In addition, there are the management areas, such as hospital management, management of clinical and non-clinical departments, administration management, and nursing management. These areas are related to *patient care*. They could be broken down further. For university medical centers, additional areas for *research and education* must be added to the above list.

The most important persons in a hospital are, obviously, patients. Important groups of persons working in a hospital are physicians, nurses, administrative staff, technical staff, medical informaticians, and health information management staff. Within each group of persons, different needs and demands on the hospital information system may exist depending on the role, tasks, and responsibilities. Ward physicians, for example, require different information than physicians working in service units or senior physicians. Patients sometimes need similar information as physicians but in a different form.

## *6.2.2 Technological Perspective*

Hospitals can be considered as quite complex institutional health care settings. Therefore, nearly all functions mentioned in Chap. 3, together with their data to be processed, have to be considered, as well as many of the application components,

nearly all of which can be part of a hospital information system. The examples in Chap. 3 were often taken from hospitals because of this fact. Consequently, integrity and integration are especially crucial when managing hospital information systems.

## *6.2.3 Management Perspective*

As hospitals are such complex entities, there are many different stakeholder groups with sometimes conficting requirements regarding the hospital's information system. These stakeholder groups include the various professional groups (physicians, nurses, administrators, researchers, teachers, etc.). In this situation, systematic information management and a carefully planned step-by-step approach of shaping the information system are essential. Thus, all tasks and methods presented in Chap. 4 have to be considered by the management of the information system. Due to the same reason, most examples in Chap. 4 were taken from hospitals.

## **6.3 Information Systems in Nursing Homes**

## *6.3.1 Characteristics of Nursing Homes*

Nursing homes are organizations primarily related to the care of persons with physical and mental functional defcits. These are often, but not exclusively, senior citizens at an advanced age. They are usually called residents.

The most important working areas in nursing homes are the wards and the residents' rooms, the administration areas, and the management areas (especially nursing management). Depending on their specialty, nursing homes may have dedicated areas for therapeutic services. Nursing homes can be of very different size, ranging from a few to hundreds of beds.

The most important persons in a nursing home are, obviously, the nursing home residents. In addition, the visitors are also of great importance and special amenities and services are provided for them as well. Important groups of persons working in a nursing home are nurses as well as administrative and management staff.

## *6.3.2 Technological Perspective*

In nursing homes, the functions to be performed are mainly those of nurses and administrative staff. The typical application component is the *nursing management and documentation system (NMDS)* that supports major functions such as *patient administration*, *decision-making*, planning, *organization of patient treatment*, and *coding*. In the event that external physicians or other specialists are involved in *patient care*, they may also document their fndings in the *NMDS*. Otherwise, they may use their own application system for documentation (such as the application system of the general practitioner (GP)). In the latter case in particular, but also in order to be able to receive prescriptions and fndings from specialists and laboratories, for example, communication links from the *NMDS* to application systems outside the nursing home are required. The interoperability standards and integration technologies from Chap. 3 can be used for this purpose. A prerequisite, however, is the physical integration discussed in Sect. 3.10.2 based on a secure data transmission connection at the physical tool layer.

## *6.3.3 Management Perspective*

*Management of information systems* in nursing homes is typically reduced. Often, senior nursing managers will be responsible for organizing *management of information systems*. Sometimes, they may be supported by the vendor of the *NMDS* which delivers and maintains the software and sometimes the hardware.

The aforementioned requirements of the technology, particularly with regard to the necessary external communication, also lead to special challenges in the area of data security. In particular, if the nursing home, unlike a hospital, does not have its own professional information managers, the management of the home must take strict care to ensure that the tasks of professional and systematic information management are nevertheless covered. It is a good idea to outsource the corresponding services to specialized external companies. But even such a solution does not relieve the home management of its responsibility for the information system.

## **6.4 Information Systems in Medical Offces**

## *6.4.1 Characteristics of Medical Offces*

Medical offces are settings where patients with acute and chronic diseases receive outpatient treatment.

The most important working areas in medical offces are the examination and treatment rooms. Further areas for patients that we must consider are waiting areas with, for example, waiting rooms. All this is similar to outpatient units in hospitals. In addition, areas for administrative purposes, for example, patient management, billing, and telephone services, can often be found in medical offces. Depending on their specialty, medical offces (in particular specialist offces) may have additional areas for diagnostic or therapeutic services.

As in hospitals, the most important persons in medical offces are patients. The three groups of persons usually working in medical offces are physicians, other health care professionals (e.g., nurses, laboratory staff, psychologists, physiotherapists), and administrative staff. Whereas hundreds or thousands of health care professionals work in hospitals, the number of persons working in medical offces is much lower, often less than 10. Information systems for medical offces have to support these persons' needs. Obviously, the complexity of information systems of medical offces is less than the one of the hospitals.

## *6.4.2 Technological Perspective*

In medical offces, the functions to be performed are mainly those of health care professionals and of administrative staff with regard to *patient care* and administration. As in other settings, application systems are needed which support functions such as *patient administration*, *decision-making*, planning, *organization of patient treatment*, and *coding*. Typically, a *patient administration system* and a *medical documentation and management systems (MDMS)*, both based on software from a single vendor, are combined into a single application system. The result is similar to the *clinical information system (CIS)* and *electronic health record system (EHRS)* discussed in Sect. 3.4.15. In the case of specialist medical offces with additional areas for diagnostic or therapeutic services, additional application systems for these functions can be found, for example, a *radiology information system (RIS)* together with a *picture archiving and communication system (PACS)* or *laboratory information system (LIS)*. If so, integration of these application systems in the offce is needed as discussed in Chap. 3.

Medical offces exchange a wide range of information with nursing homes, laboratories, hospitals, specialists, and other care facilities. Therefore, secure interfaces for external communication must also be provided for its application systems (Chap. 3).

## *6.4.3 Management Perspective*

Medical offces are sometimes independent "small enterprises". Other times, they are part of a larger health care facility. Medical offces are even smaller than nursing homes and can hardly have their own information management staff. If the medical offces are independent enterprises, however, they still need to take responsibility for the information management. Ensuring data security in particular must not be neglected under any circumstances. The owner or the management of the medical offce will then be responsible for the management of the information system,

sometimes supported by consulting companies, which also deliver and maintain hardware and application software products for application systems in these offces. If the medical offces are part of a larger health care facility, information management is usually handled by the IT departments of these facilities.

## **6.5 Information Systems in Ambulatory Nursing Organizations**

## *6.5.1 Characteristics of Ambulatory Nursing Organization*

Ambulatory nursing organizations are primarily related to the care of persons with physical and mental functional defcits living at home. These are often, but not exclusively, senior citizens at an advanced age that are visited regularly by ambulatory nurses.

The most important working areas therefore are the patients' homes as well as an administrative offce area where the visits are coordinated. The most important persons working for ambulatory nursing organizations are nurses, supported by administrative and management staff. Ambulatory nursing organizations can be of very different size, from a few to hundreds of nurses.

## *6.5.2 Technological Perspective*

Ambulatory nursing organizations need support for the overall coordination and organization of the visits at the patients' homes as well as for nursing management and documentation, done mostly at the patients' bedside, and for administration and billing. The respective functions are compiled in Table 3.3.

Ambulatory nursing organization may use an *NMDS* that also offers special features for organization and coordination of visits at patients' home. At the physical tool layer, mobile tools are often used to facilitate information processing at the patients' homes when using the *NMDS*.

## *6.5.3 Management Perspective*

As for medical offces, ambulatory nursing organizations may be small enterprises or part of larger organizations. *Management of information systems* in ambulatory nursing organizations depends on the size of the organization here as well. The owner or the management of the organization will then be responsible for the management of the information system. Sometimes, they may be supported by the vendor of the *NMDS* which delivers and maintains the software and sometimes the hardware as well.

## **6.6 Information Systems in Medical Research Facilities**

## *6.6.1 Characteristics of Medical Research Facilities*

Medical research facilities exist in a variety of shapes and with different characteristics. Medical research is conducted at university medical centers, for example, in specialized working groups, institutes, or sub-units, but may also be conducted in universities, associated institutes, or industrial facilities, for example, in the pharmaceutical industry. Medical research usually is interdisciplinary and involves heterogeneous data on various entity types, for example, "clinical trial," "fnding," or "classifed diagnoses" (Sect. 3.2.3.4). Especially in academic centers, effcient *research and education* must be supported. The objective of clinical research is the generalization of fndings and experiences to gain new knowledge. Data documented during the patient treatment process may be reused for retrospective analysis to fnd evidence for generalization and to generate hypotheses for new studies.

## *6.6.2 Technological Perspective*

Research facilities are very different from patient care facilities in terms of the functions to be performed and also in terms of the application systems to be used. For this reason, we will discuss both the specifc functions and the application systems in more detail below. The following specifc information processing functions need to be supported (Fig. 6.2).

Experiments and clinical trials are important for the progress in medicine because they update biomedical and health knowledge. Scientifc staff must be supported in *planning, executing, and analyzing studies and experiments*. Planning and execution must conform to legal requirements. For example, patients have to be informed of opportunities and risks before they can consent to taking part in a clinical trial. Data documentation needs to fulfll the de facto standard of minimal requirements for managing research data, the FAIR criteria for research data management: fndable, accessible, interoperable, and reusable. Signifcant progress in research, for example, in generating new hypotheses for later prospective studies or by uncovering new pathomechanisms or pathways associated with diseases, is also achieved through retrospective analysis of large amounts of heterogeneous data. These datadriven scientifc approaches must also be supported by research facilities.

**Fig. 6.2** Extract of the domain layer of the 3LGM2 -based reference model describing the function *research and education*, its subfunctions and interpreted and updated entity types

Finally, for research data, processes of pseudonymization and/or anonymization must be supported wherever necessary in order to conform to legal requirements.

Scientifc staff needs to *prepare publications and presentations*. Therefore, central collections of both the facility's relevant publications and other literature need to be made available to them using a standardized interface. Scientifc staff needs access to research-relevant information and general medical knowledge.

Medical casuistic and treatment data must be made available for *training and education* in medical professions. Furthermore, the *organization and execution of teaching and exams*, for example, through e-learning tools and tools for taking electronic exams, must also be supported.

*Research management* is executed in all of the hospital's organizational units which decide on planning, monitoring, and directing research activities. This includes the documentation of research activities as well as the management of third-party funds and the management of scientifc sub- or service units within facilities.

To implement the above-mentioned functions, numerous different application components usually exist. Frequently, medical research facilities run multiple decentralized database systems or repositories for specifc research purposes, projects, or trials. Clinician scientists often call these "cohort" databases, refecting the longitudinal or cross-sectional nature of data capture. Dedicated research data management offces support researchers in creating such data repositories or registries in accordance with FAIR criteria by consulting them in terms of how to plan, conduct, and document research projects and by supporting them in selecting standards for structuring, representing, and saving their data along with appropriate metadata, thus aiming for a certain degree of interoperability and reusability.

For clinical trials which have to fulfll very high standards with regard to data quality, data monitoring, versioning, etc., dedicated electronic data capture (EDC) systems are used. These offer customizable data entry forms and various export formats, most notably using CDISC standards (Sect. 3.7.2.11).

Data from clinical application systems which are provisioned for reuse in research are frequently stored in data warehouse systems (DWS), data lakes (repositories for raw, often unstructured data), or *open platforms* (Fig. 6.3). If the facility does not run an *open platform*, all of the above require some sort of export (e.g., as Health Level 7 (HL7) messages, HL7 FHIR) or extraction process from clinical application systems. While data lakes incorporate raw data such as fles, blobs, or genomic sequences, DWS, as invariant systems for research, require an extract, transform, load (ETL) process, during which quality checks, and mapping to terminologies may be performed. *Open platforms*, in contrast, provide care-level, longitudinal patient-related data of the highest quality and semantic defnition, so that clinical or research applications as well as registries can be built upon them. For research purposes, a research copy of the EHR with pseudonyms may be used.

With rising needs of cross-institutional or international research collaboration, data sharing, and integration, many medical research facilities establish central units called data integration centers (DIC). They integrate data and run all systems that enable cross-institutional querying and data exchange, while at the same time

**Fig. 6.3** Logical tool layer: application components supporting the reuse of clinical data during "planning, execution and analyzing studies and experiments"

taking care of use-and-access processes and their documentation, data protection and safety, consent management, and all activities related to data integration and semantic enhancement (e.g., terminology binding).

Medical research requires a great deal of creativity, and the application and database systems used must be fexibly adaptable to new research questions being investigated. Therefore, it is necessary to enforce the use of open standards for data representation, so that the data are reusable in future projects and in different contexts. Likewise, open interfaces and standardized query languages are necessary for data access. This facilitates rapid and fexible software development for research.

Systems for research often demand huge storage capacity as well as adequate network bandwidth, particularly in the disciplines concerned with omics (e.g., in metabolomics) or imaging data. Research organizations must anticipate future storage needs and provide adequate physical storage systems as well as highly performant computing infrastructures for extensive analyses of large and heterogeneous datasets. For this purpose, facilities frequently run their own high-performance computing clusters, including special GPU (graphics processing unit) systems. Employing cloud solutions may also be useful to share computing capacities with other research facilities.

Medical research is also dependent on international cooperation, which requires even more fexible options for digital communication beyond the boundaries of the facility than is necessary for health care facilities. When research facilities are part of a health care facility, the physical data processing systems of the research facility are therefore connected in a separate part of the communication network that is strictly separated from the communication network of the health care facility.

## *6.6.3 Management Perspective*

Information systems in medical research facilities demand dedicated and specialized management for optimal support of research endeavors. To fulfll FAIR criteria and in particular to enable data reuse and sharing within and across facilities, it is crucial to avoid home-made research infrastructures (e.g., using spreadsheets or proprietary databases) which are not or only partly interoperable with other systems. From a management perspective, it is crucial to defne and enforce rules, processes, and standards for representing, storing, and sharing research data. To achieve this, dedicated research data management units can provide consultation and support for researchers, at the same time supervising a coherent management strategy. If they exist, these units may work closely together with DICs.

Strategic planning and establishing a strategic information management plan is particularly challenging in research institutions for two reasons. Firstly, it is diffcult to foresee which research questions will have to be addressed in 5 years' time. As a result, the application systems required for this purpose can also be predicted less well than in health care facilities. It is therefore necessary to plan primarily for generic tools and also software development groups in order to be able to adapt quickly to new research questions. Secondly, research is often funded on a project basis. Thus, it is often only known at fairly short notice what funding is available for the procurement of software and hardware; for the long-term maintenance and servicing of components, the necessary funds can often only be made available on an ad hoc basis. Consequently, a strategic information management plan will tend to provide a broad framework for the development of the research institution's information system and focus on infrastructure (Sect. 2.11).

## **6.7 Information Systems in Other Health care Settings**

In addition to the institutional health care settings already mentioned, there are a number of other institutions involved in health care services for people. These include:


## *6.7.1 Characteristics of Other Health care Settings*

#### **6.7.1.1 Pharmacies**

Pharmacies are settings where persons with acute or chronic diseases or for preventive purposes can obtain prescription-only or non-prescription medications as well as medical aids.

A pharmacy usually consists of three areas. The free-dial area refers to the sales area in front of the counter where non-pharmacy products are offered, such as bandaids, toothpaste, and teas. The area behind the counter, which is clearly visible to all customers, is called the sight-selection area. Here, a person will fnd pharmacy-only products that can be purchased without a prescription, such as light pain analgesics, cough syrups, or nasal spray. In the last area, the pharmacy warehouse, which is usually structurally separated from the sales area, prescription-only medications are stocked in special shelving systems and pharmacy lockers.

Many different professional groups are employed in pharmacies. The most important people working in pharmacies are pharmacists. They are the experts on medicines and are responsible for, among other things, the production and dispensing of medicines and advising patients. Every pharmacy must have at least one pharmacist on site at all times. In addition, there are a number of pharmaceutical personnel, such as pharmaceutical technical assistants, pharmacist assistants, and pharmaceutical assistants. However, non-pharmaceutical personnel also operate in pharmacies. These include pharmaceutical commercial assistants, pharmacy assistants, and skilled pharmacy workers.

#### **6.7.1.2 Therapeutic Offces**

There is a variety of different therapeutic offces that provide (therapeutic) treatment for people in the outpatient sector. These include offces for physical therapy, physiotherapy, occupational therapy, speech therapy, and massage therapy. In addition to the relief of physical complaints, however, there are also therapeutic offces for relieving mental complaints, such as psychotherapists or learning therapists.

Therapeutic offces, similar to medical practices, consist of a waiting area, a registration area with a reception desk, and one or more treatment rooms. The equipment of the individual treatment rooms depends on the therapeutic measures to be performed. Depending on the range of services provided by a facility, there may also be additional areas for specifc therapeutic services. In physiotherapy practices, for example, it is not uncommon to fnd individual equipment areas for performing physiotherapy exercises.

Alongside patients, therapists are the most important professional group in therapeutic practices. Depending on the specialization of a therapeutic offce, these include masseurs, physiotherapists, occupational therapists, or respiratory, speech, and voice teachers. The tasks to be performed vary considerably depending on the professions, but usually include both advanced diagnostics and therapy.

Quite often, medical assistants also work in therapeutic practices. They take on administrative and supporting activities.

#### **6.7.1.3 Inpatient and Outpatient Rehabilitation Facilities**

There are both outpatient and inpatient rehabilitation facilities of all sizes. Rehabilitation facilities are settings in which patients with a health condition are enabled "to remain in or return to their home or community, live independently, and participate in education, the labor market and civic life" [1]. For this purpose, rehabilitation facilities often focus on a specifc discipline. For example, there are rehabilitation centers specialized in cardiological, neurological, or orthopedic rehabilitation.

Inpatient rehabilitation facilities, also called rehabilitation centers, are comparable to hospitals. Thus, there are also different wards and service areas which must be supported by an information system: patient rooms, community areas, treatment areas for individual and group therapy, administrative areas (e.g., patient administration department, fnancial and controlling department), and also a kitchen/ canteen.

Outpatient rehabilitation centers are comparable to therapeutic offces, only that they are larger and usually offer a wider range of functions.

The most important people in rehabilitation facilities are the patients. Among the most important employees are the medical staff as well as various therapists (e.g., occupational therapists, speech therapists, and physiotherapists), nurses, and social workers. Alongside the medical-therapeutic staff, there are also a large number of employees in administrative areas, for example, typists, therapy planners, and receptionists. On top of this, there are various service employees, such as housekeepers and kitchen staff. The number of employees per facility strongly depends on the size and scope of the services provided.

#### **6.7.1.4 Hospices**

Hospices focus on the palliative care of critically ill patients and of persons passing away. Apart from relieving pain and enhancing the individual's quality of life in their fnal phase of life, the tasks also include providing bereavement services for relatives. In addition to inpatient hospices, there also are outpatient hospice services that provide support for patients and relatives in their own homes or in an inpatient care facility.

Inpatient hospices are relatively small (8–16 beds) and consist of areas similar to inpatient care facilities. Alongside the patients' rooms, hospices also have a reception area, administration, community rooms, guest rooms for relatives, staff rooms, and a kitchen.

Hospice care is provided by an interdisciplinary team. Alongside nursing staff with an additional palliative qualifcation (palliative care nurse), chaplains, psychologists, and social workers, hospice volunteers with training as assistant dying companions are also among the most important employees of hospices. There are also administrative staff and housekeepers. The number of nursing staff in a hospice depends on the number of beds available. In Germany, there is a care contract for inpatient hospice care that contains corresponding indications. Hospices, like inpatient nursing homes, do not have their own medical staff. Medical care is provided by physicians from general practices (primary care physicians) or from attached hospitals.

#### **6.7.1.5 Wellness Facilities**

Especially in the context of tertiary *prevention*, certain facilities play a role that one would not necessarily think of frst in the context of a health care setting. For example, various wellness activities to increase well-being and relaxation, such as massages, can be performed in specifc wellness centers, wellness, and cosmetic studios, but also in hotels specialized in this feld. The main working areas in wellness facilities are the treatment rooms and, depending on the range of services, other additional areas for specifc therapeutic services. In addition, there are reception or registration areas for administrative purposes and, in some facilities, also waiting rooms.

Besides the customer, or patient, the therapeutic staff, such as masseurs, physiotherapists, or sports therapists, are among the most important people of wellness facilities. The list of employees is completed by administrative staff. The number of employees depends on the size of the facility. In small wellness and cosmetic studios, there are often less than 10 people working there.

#### **6.7.1.6 Sports Centers and Leisure Parks**

Tertiary *prevention* may also coincide with rehabilitation. Sometimes, ftness activities can be performed not only in certifed rehabilitation facilities but also in regular sports studios and sports parks. Furthermore, activities for primary *prevention* may be carried out in sports facilities.

Conventional ftness studios consist of various functional areas. The cardiovascular area is particularly suitable for improving general ftness and thus preventing diseases promoted by a lack of physical activity, such as high blood pressure and diabetes. Functional ftness areas with, for example, medicine balls and kettle bells as well as free weight areas are used for strengthening. Targeted strengthening of the shoulder, back, and neck muscles, for example, can reduce the risk of musculoskeletal disorders of the shoulder and back.

Customers, or members of a sports center, are one of the most important groups of people at sports centers and leisure parks. In addition, there are various service employees who are responsible for advising customers on site, assisting members at the reception desk, and offering sales services. Various specialized (ftness) trainers are responsible for training support and advice. The number of employees depends to a great extent on the size of a facility.

## *6.7.2 Technological Perspective*

It is already clear from the basic characteristics described above that there are considerable differences in the functions to be performed depending on the facility or setting. In therapeutic practices and rehabilitation facilities, as in doctors' practices and hospitals, the focus is on the medical or therapeutic treatment of people. The function of pharmacies, on the other hand, is to supply people with medicines and medical aids. For this purpose, it is necessary to produce, store, and test drugs, as well as to dispense these drugs to the patients and inform them about the intake, storage, and risks of a drug (advice).

Consequently, these diverse information processing functions also result in different requirements with regard to the application components that are usually used. While application components for prescription and medication management as well as specifc pharmacy resource planning systems are used in a pharmacy, therapeutic practices such as medical practices have *patient administration systems* for admitting and registering patients, *MDMS* for documenting the therapeutic measures performed, and *patient administration systems* for billing purposes. Even if wellness facilities and sports facilities do not focus on a person as a patient, they nevertheless also have application components for scheduling, documenting the services performed, and billing.

## *6.7.3 Management Perspective*

Due to the considerable differences in the functions to be performed in the various facilities or settings, the way in which *management of information systems* is organized also differs. The more complex the functions are, and the more persons are involved, the more *management of information systems* will be organized in a dedicated way as in hospitals. In the case of smaller settings and/or limited information processing functions, *management of information systems* might be assigned as an additional task to the management in these settings. As in medical offces, these persons might be supported by consulting companies, which may also deliver and maintain hardware and application software products for application components.

## **6.8 Information Systems in Personal Environments**

## *6.8.1 Characteristics of Personal Environments as Health care Settings*

Probably, the most important personal environment for persons are their homes. As personal environments, we may also regard workplaces and transport vehicles such as cars. As mentioned in Chap. 1, we primarily associate personal environments with our regular daily lives. Personal environments, however, may also be related to health care. Thus, besides supporting primary *prevention* and wellness for healthy people, personal environments may also support diagnostic and therapeutic activities, rehabilitation, or secondary and tertiary *prevention* (i.e., to reduce or soften the impact of a disease that has already occurred). Health care activities in our personal environments are often denoted with terms starting with "tele" or "home," for example, telecare, telemedicine, telerehabilitation, or home care.

## *6.8.2 Technological Perspective*

In the case of tele-activities supporting diagnostics or rehabilitation, these activities are often assigned to health care facilities such as hospitals, medical offces, or ambulatory nursing organizations. In this case, the functions and application systems can be regarded as part of the information systems of these settings. However, the information processing activities of these settings do not end within the walls of these settings but take place in a personal environment. Therefore, technical complexity is higher and efforts with regard to data privacy and security are more demanding, as informational self-determination is a very sensitive matter.

In the case of wellness and of primary *prevention*, the situation is different. Here, persons install application systems as introduced in Chap. 3 on their own and use these in their personal environments.

## *6.8.3 Management Perspective*

In the case of activities which can be assigned to health care settings such as hospitals, medical offces, or ambulatory nursing organizations, *management of information systems* is primarily done by these settings. In other activities, for example those related to wellness or primary *prevention*, the persons themselves are responsible. We would hardly call this *management of information systems* although it would technically be correct.

## **6.9 Information Systems in States and Regions**

## *6.9.1 Characteristics of States and Regions as Health care Settings*

In the Universal Declaration of Human Rights of 1948, the right to health is found as part of the right of all people to an adequate standard of living. In the International Covenant on Economic, Social and Cultural Rights (ICESCR) of the United Nations, as well as in other UN human rights treaties, the states commit themselves to ensuring adequate, non-discriminatory health care.

Usually, the government health ministries of the states are responsible for health care. Depending on the constitution and size of the states, there are both centralized and federal structures. But in most cases, parts of the overall responsibility are delegated to subordinate structures such as federal states, provinces, regions, and municipal units.

Even if the responsibility always remains with the (central) government in the end, health care institutions are organized very differently in the individual countries. In the United Kingdom, for example, the vast majority of health care facilities are part of the state-run National Health Service. In Germany, facilities can be privately owned or publicly owned, such as by cities and countries, but they are always subject to state supervision. The fnancing of the health care systems also differs. There are state-fnanced health care systems, systems of almost nationwide compulsory insurance for all citizens that bear the costs of care, or systems where citizens must bear the costs themselves. However, the differences can be quite fuid.

The network of health care in a state or region consists, as already mentioned in Sect. 2.6, not only of hospitals and medical offces but also of responsible government agencies and insurance companies, among other things. The global pandemic that broke out at the end of 2019 in particular highlights the importance of municipal health departments, national disease control authorities (e.g., the Robert Koch Institute in Germany), and international institutions (e.g., the European Centre for Disease Prevention and Control (ECDS) and the World Health Organization (WHO)). However, it also highlights the importance of networking among these agencies.

## *6.9.2 Technological Perspective*

We already know from Sect. 2.6 that every state and region in which there is a network of health care facilities already has, by defnition, a transinstitutional health information system (tHIS). However, such tHIS are supported by computers to quite different degrees depending on the country. Networking between actors requires communication and interoperability of the systems involved, just as it does within institutions. Very often—even in rich industrialized countries—this communication takes place by telephone or postal communication or even by fax.

The tHIS of states or regions are composed of the institutional information systems of the institutions participating in the network. These information systems thus incorporate the entire range of application systems described in Sect. 3.4 into the tHIS. In order for the institutional information systems to be interoperable with each other, they must each have interoperable application systems through which they can communicate with the other institutional information systems and thus work together. All aspects of interoperability and integration discussed in Sects. 3.7 through 3.10 play a role in this process, and use of the interoperability standards discussed in Sect. 3.7.2 is essential. For example, in Austria, and increasingly in Germany, Integrating the Health care Enterprise (IHE) profles and especially XDS are used for this purpose (Sects. 3.7.2.5 and 3.7.2.6). However, FHIR is becoming increasingly important.

Especially for government agencies and ministries of health, other application systems are required in addition to those explained in Sect. 3.4. The WHO describes 25 types of such application systems in its WHO Classifcation of Digital Health Interventions [2]. However, at this point, the WHO's terminology does not match the terminology in our textbook, so the application systems at WHO are usually referred to as information systems. Examples of such types of application systems are "community-based information systems" (WHO category F) and "public health and disease surveillance system" (WHO category V). The "district health information systems" frequently mentioned in the literature must also be understood as application systems that must work together with the other application systems of the tHIS via interfaces.

It makes sense if, in a national health care system and also at the international level such as the European Union, a computer-supported infrastructure is available at the physical (Sect. 3.10.2) and logical level of the tHIS through which the institutional information systems can communicate with each other in a standardized manner. In Germany, for example, this infrastructure is known as the telematics infrastructure.

Worldwide, tHIS are developed very differently at the country level. The level of development—sometimes called digital maturity—cannot be determined solely by the availability of modern IT. What matters most is whether this technology actually brings benefts to health care. A study conducted in 2020 therefore analyzed in various countries whether patients, their caregivers, and medical staff in hospitals or other facilities can read and enter the data required for health care. Even rich industrialized countries performed very poorly [3].

## *6.9.3 Management Perspective*

Responsibility for tHIS at the state or regional level falls to the relevant government agencies. These are usually the ministries of health. The framework for tHIS development and responsibilities are defned by law.

Sometimes, as in Estonia, for example, there is a state chief information offcer (CIO) who is also responsible for the nationwide tHIS of the health care system. In Estonia, this CIO is responsible for the national infrastructure and the use of communication standards. In other countries, like Finland, for example, responsibility for the national tHIS is decentralized and regional structures, for example, provinces or federal states have responsibility. In Germany, there is a company controlled by the Federal Ministry of Health, GEMATIK, which is responsible for setting up and operating the telematics infrastructure in the country.

## **6.10 Life Situations and Their Consequences for Orchestrating Services in Transinstitutional Health Information Systems**

In Sect. 1.2, we already saw that people in different life situations are concerned about and have to deal with their health. These life situations are closely linked to the settings we discussed in the previous sections of Chap. 6. For example, *prevention* and wellness are closely linked to the different settings we discussed in Sect. 6.7 but also to personal environments (Sect. 6.8). Medical emergencies and acute illness are taken care of by both hospitals (Sect. 6.2) and medical offces in ambulatory care settings (Sect. 6.4). These settings are also there for the treatment of chronic illnesses, but it is precisely in this life situation that the personal environment and one's own home also become therapeutic spaces where, for example, the attending physician comes for a home visit and patients acquire knowledge about their illness, seek advice via the internet, or plan necessary visits to the doctor and specialists (Sect. 3.3.1). Care of the elderly or people with chronic diseases takes place both in the nursing home (Sect. 6.3) and in the personal environment, if necessary with the support of an ambulatory nursing organization (Sect. 6.5). Rehabilitation facilities prepare patients for a more "normal" life after emergencies and acute illnesses but also when chronic illnesses improve.

This summary shows us clearly that people need very different health care services from different health care settings in different places during their lives. We introduced the notion of tHIS in Sect. 2.6, which summarizes the information processing in and between all these health care settings.

Ultimately, the challenge remains for each person to arrange for themselves to fnd the services they need in the tHIS and to ensure that the services ft together and are appropriate for treating their condition. Many are grateful when relatives and friends help with the search. GPs can also help to a limited extent.

In the context of service-oriented architectures (SOAs, Sect. 3.9.4), we are familiar with the need to compile required services when taking a technical view of health information systems. We refer to this as the orchestration of services. We can also apply this term to the challenge of citizens to fnd suitable medical services and combine them appropriately.

Given the complexity of medical services and the medical expertise required to orchestrate them, family doctors and hospitals, as already mentioned, take on part of the orchestration and organize, for example, the necessary visit to a specialist. We refer to this as provider-induced orchestration. But even with such support, patients will still need to independently seek appropriate transportation, i.e., other, nonmedical services. And often, referrals to specialists will only specify the type of specialist; patients will have to fnd the exact person or facility themselves. So the patient is left with plenty of complex tasks, which we call patient-induced orchestration.

In this situation, it is very helpful if the information about offered medical as well as non-medical services is available for the citizens. But in the enormous complexity of transinstitutional health information systems and the abundance of

corresponding information, not only elderly people are quickly overwhelmed with this patient-induced orchestration. The question arises to what extent information technology can also help to fnd the services needed in a particular health situation and ensure that they ft together. For example, it must be ensured that that specialists are selected only in such a way that they can be reached from patients' homes by public transport during their consultation hours. Although there is promising research on this customer-induced orchestration, much remains to be done.

## **6.11 Example**

To support medical research and care, the German Medical Informatics Initiative (MI-I) was launched. Four consortia of university medical centers are establishing the so-called data integration centers (DICs) for the individual hospitals. These DICs are facilities that extract data from the electronic patient records of the respective hospitals to make them available for research projects. Note that in each hospital, the data from the electronic patient records is scattered around the various application systems of this hospital. The consortium SMITH (Smart Medical Information Technology for Health care) decided to apply IHE to share data between the hospitals and the DICs as well as between the DICs of the different hospitals. For details, see [4].

Figure 6.4 shows the high-level functions to be performed and the entity types involved in a 3LGM2 model. The dotted lines indicate that there are still refnements to the corresponding tasks and entity types. Patient data ("EMR Data in UH Sources") is taken from the electronic patient records of hospitals ("University Hospital (UH)") and inserted into a separate storage area. There, the data are prepared and, in particular, semantically "nourished," i.e., enriched. Also, certain rules and methods for processing the data are managed in this "Health Data Storage." When the patients to whom these data belong have given their consent, the data are pseudonymized by a trustee unit and made available to research projects by the "Transfer Management."

At each DIC's site, application systems are needed to support the local DIC, i.e., supporting the execution of functions as well as storing and communicating the entity types. Data and knowledge sharing between sites and between patient care and research projects (Research & Development Factory) have to be enabled. Communication is standards-based, especially using IHE profles, CDA, FHIR, and SNOMED to ensure syntactic, semantic, and process interoperability.

The architecture of the local information system and their communication links at each site follows the DIC reference architecture as outlined in the 3LGM2 model in Fig. 6.5. Using IHE profles, the local sub-information systems of the entire tHIS of the SMITH network (SMItHIS) are integrated. While applying the DIC reference architecture locally, the reference architecture allows for local peculiarities.

As mentioned before, the DICs have to ingest data from various data sources, i.e., different application systems of the local hospital information

**Fig. 6.4** High-level functions and entity types of data integration centers in SMITH

**Fig. 6.5** SMITH-DIC Reference Architecture at the logical tool layer

systems. Communication between application systems is classifed into three categories, A, B, and C, according to their interface type ("if-type") (see legend in Fig. 6.5). Sources of Type A are designed using IHE profles. There are application systems that can serve HL7 and DICOM standards but do not fully implement IHE profle. They are referred to here as Type B sources. Type C sources are proprietary, such as data provided by comma-separated value (CSV) fles.

The "Data Integration Engine" executes data transformation and load processes from sources into the health data storage (HDS). The HDS contains both a component for storing HL7 FHIR resources (Health Data Repository) and an IHE XDS document repository comprising clinical data in HL7 CDA documents. Using the interface-type scheme (A, B, and C), data are shared beyond department borders. Precise explanations of other details can be found in [4].

## **6.12 Exercises**

## *6.12.1 Research Architecture*

A clinical researcher at Ploetzberg Hospital has won a grant to set up a register for patients who have received a knee endoprosthesis. Disease registers are research databases for collecting data about a specifc disease, aiming for full coverage of the respective patient collective. The aim of a knee endoprosthesis registry is to collect longitudinal data to fnd out which type of endoprosthesis works best over time. The researcher wants to integrate data from patient-reported outcome questionnaires, fndings from inpatient or outpatient visits at the hospital, and results from laboratory examinations. Which entity types need to be integrated and from which application components do they come? Devise a plan how you would set up a sustainable research architecture, i.e., an architecture that also could be used in other research settings and for different disease or research entities, considering Sect. 6.6.

## *6.12.2 Medical Admission*

In which of the health care settings above will the function *medical admission* need to be supported?

## **References**


**Open Access** This chapter is licensed under the terms of the Creative Commons Attribution 4.0 International License (http://creativecommons.org/licenses/by/4.0/), which permits use, sharing, adaptation, distribution and reproduction in any medium or format, as long as you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons license and indicate if changes were made.

The images or other third party material in this chapter are included in the chapter's Creative Commons license, unless indicated otherwise in a credit line to the material. If material is not included in the chapter's Creative Commons license and your intended use is not permitted by statutory regulation or exceeds the permitted use, you will need to obtain permission directly from the copyright holder.

# **Solutions to Exercises**

## **Chapter 1: Introduction**

#### **Exercise 1.5.1 Life Situations**

My father was admitted to the hospital after suddenly showing symptoms of numbness in the left arm, confusion, and trouble seeing while at home. We called the ambulance, and after a short examination, the ambulance team took him to the nearest hospital for further diagnosis and treatment. This situation corresponds to an emergency life situation. I participated in this situation as a close relative. My urgent requirements were to know which hospital my father was taken to and to obtain more information on the suspected diagnosis (here: stroke) and the next steps of diagnosis and therapy.

#### **Exercise 1.5.2 Requirements of Various Stakeholders**

While a patient is being treated for an acute disease, the requirements of the treating physicians and nurses as well as of the patient and relatives may differ. For example, patient and relatives want to be kept informed of ongoing diagnostic outcomes (e.g., lab values) as soon as possible. However, physicians and nurses may want to discuss the fndings with the patient in person to avoid causing unnecessary confusion and stress in the patient. Therefore, the health information system must be able to provide detailed information to physicians and nurses, but it must be able to only present confrmed information to the patient (e.g., via a patient portal).

## **Chapter 2: Basic Concepts and Terms**

#### **Exercise 2.16.1 Data, Information, and Knowledge**

"160," "100," "hypertension," and "blood pressure" represent data that cannot be interpreted without knowledge about the context. The information is that Mr. Russo has been diagnosed with hypertension and that his last blood pressure is

<sup>©</sup> The Editor(s) (if applicable) and The Author(s) 2023

A. Winter et al., *Health Information Systems*, Health Informatics, https://doi.org/10.1007/978-3-031-12310-8

160/100 mmHg. The medical knowledge embedded in this example is that a blood pressure of 160/100 mmHg indicates hypertension that should be treated.

#### **Exercise 2.16.2 Systems and Subsystems**

The nervous system comprises two main categories of cells: neurons and glial cells. Neurons communicate with each other via synapses and thus form their own subsystem. Glial cells form another subsystem that provides support and nutrition to the neurons.

The hospital can be understood as a system comprising at least two subsystems: the subsystem where clinical care takes place and the subsystem where management takes place. The clinical subsystem can again be split into several subsystems, such as inpatient area, outpatient area, and specialized diagnostic or therapeutic areas. The inpatient area itself can be divided into various subsystems, each represented by one ward. The way I defne the subsystems of a hospital depends on the questions or intentions I have.

#### **Exercise 2.16.3 Information Logistics**

The physician wants to have access to the right information (the most recent blood pressure) at the right time (when talking to Mr. Russo) at the right place (at the patient's bedside) in the right form (hopefully the blood pressure is provided in an easy-to-grasp, visual way) so that he can make the right decision (here: to decide on the level of a certain medication). If the information system does not support this, the physician may obtain an incorrect or outdated blood pressure measurement, or he may misinterpret it, thereby coming to a decision that is suboptimal for the patient.

#### **Exercise 2.16.4 3LGM2 Metamodel**

Administrative admission is an enterprise function that is supported by the patient administration system. One entity type that is used and updated by this function is "patient." The paper-based patient data privacy form system is an example of a noncomputer-based application component. The virtualized server farm is an example of a physical tool. The inter-layer relationships of this example show which functions are supported by which application system and which physical data processing system the application systems are installed on.

#### **Exercise 2.16.5 Interpreting 3LGM2 Models**


## **Chapter 3: Technological Perspective**

#### **Exercise 3.12.1 Domain Layer: Differences in Hospital Functions**

A typical hospital needs all functions to function as expected. The functions to be performed by health care professionals are mostly similar in all health care facilities, independent of their size. Only some functions may differ. For example, not all health care facilities are involved in clinical research, thus their information will not need to support the function research and education.

#### **Exercise 3.12.2 Domain Layer: Different Health care Professional Groups and Health care Facilities**

Physicians: Important functions are medical admission, decision-making and patient information, planning and organization of patient treatment, order entry, execution of diagnostic and therapeutic procedures, coding of diagnoses and procedures, and medical discharge and medical discharge summary writing.

Nurses: Important functions are nursing admission, decision-making and patient information, planning and organization of patient treatment, order entry, execution of nursing procedures, and nursing discharge and nursing discharge summary writing.

Administrative staff: Important functions are patient identifcation, administrative admission, and administrative discharge and billing.

#### **Exercise 3.12.3 Domain Layer: the Patient Entity Type**

The entity type "patient" is updated by the function "patient admission." All other functions that are related to patient care interpret it.

#### **Exercise 3.12.4 Logical Tool Layer: Communication Server**

Short-term advantages: The communication server can handle the communication between all four application systems, including receiving, buffering, transforming, and multicasting of messages. It can also be used for monitoring the communication

traffc. The communication server thus supports data integration in heterogeneous information system architectures.

Long-term advantages: In the resulting (ACn , CP1 ) architecture, new application components can easily be integrated, as only one communication interface to the communication server needs to be implemented.

Standards: For the exchange of administrative data, HL7 V2 or V3 could be used as syntactic or semantic standard. For the exchange of clinical data, various communication standards can be chosen such as HL7 FHIR, DICOM for medical images, or HL7 CDA for clinical documents.

**Exercise 3.12.5 Logical Tool Layer: Integration from the User's Point of View** Data integration would be considered high when the nurse documents patient administrative data only once in the patient administration system and then can use this data in the NMDS.

Semantic integration would be considered high when the nurse documents a nursing diagnosis using a standardized terminology (such as NANDA) and when this standardized diagnosis is then understood by the NMDS that may, for example, suggest a standard nursing care plan for this patient based on this diagnosis.

User interface integration would be considered high when the user interfaces of both application systems look suffciently similar, which reduces the risk of data entry or data interpretation errors. For example, in both application systems, the names of the patients are always displayed at the same place, the birthdates are presented in standardized form, and colors that are used to highlight important information are used in the same way.

Context integration would be considered high when the user context and the patient context is preserved when the nurse shifts from one application system to the other. The nurse thus would not have to repeat user login or the selection of the patient in the second application system.

Feature integration would be considered high when only the patient administration system offers the needed administrative features (such as documentation of patient address). The nurse would be able to call up these features from within the NMDS.

Process integration would be considered high if both application systems work together in a highly integrated way so that the process of patient admission and nursing care planning from the point of view of the nurse is supported in an effcient way.

#### **Exercise 3.12.6 CityCare**

(a) EHR systems as comprehensive application systems combine the functionalities of MDMS, NDMS, and CPOE systems. The EHRS of CityCare could therefore be used for medical admission, preparation of an order, or execution of diagnostic and therapeutic procedures. However, each of the three health care facilities in CityCare has its own MDMS. Therefore, the EHRS is probably mainly used for accessing fndings from the other health care facilities, for example, during medical admission. For the VNA, no suitable function is modeled at the domain layer. At the domain layer, archiving of patient information

could be added which is supported by the VNA and, to some extent, also by the EHRS.


Pros (examples):


Cons (examples):


Resolving these redundancies (examples):


performed: appointment scheduling, medical admission, order entry, and preparation of an order (see matrix view in Fig. 3.35).

The application systems used in CityCare should be made available by server clusters with redundant servers. If one server in a server cluster fails, another server can take over its task. Thus, there is no interruption in function support.

(f) Yes, it makes sense to use further integration profles from IHE. For example, IHE XDS could be used. The CityCare network could be established as an affnity domain with several actors that interact in a standardized way (process interoperability) to share document-level or even large binary patient data, such as fndings, images, or radiology reports. These documents would be registered centrally in a document registry and could be retrieved by other systems. Depending on how the central EHRS is implemented, it could either take the role of a document registry that forwards the requests to a decentral source, or it could—as in our case of a central database—act as a central document provider itself.

## **Chapter 4: Management Perspective**

## **Exercise 4.9.1 Activities of Managing Information Systems**


## **Exercise 4.9.2 Strategic Alignment of Hospital Goals and Information Management Goals**

Goals: effcient and high-quality information logistics to support patient care.

Functions: patient administration and all functions related to patient care (Sect. 3.3.2.1).

Project portfolio and migration plan:


Please note: This is a simplifed solution. Other solutions may be valid, too. In case the different application systems are meant to come from different vendors, an integration technology such as a communication server needs to be implemented.

## **Exercise 4.9.3 Structure of a Strategic Information Management Plan**



#### **Exercise 4.9.4 An Information-Processing Monitoring Report**

#### **Exercise 4.9.5 Relevant Key Performance Indicators**

Several solutions are possible here. One possible solution:


#### **Exercise 4.9.6 Organizing User Feedback**

User groups: physicians, nurses, technical staff (e.g., lab, radiology), and management staff—these groups are typically large health information systems user groups. I would also organize regular survey of CIS key users, as they are experts in judging the quality of the information systems.

Organization of user feedback: (1) Health information system users are randomly invited to an automatic short and standardized survey that is displayed during CIS login. (2) Every half year, I would organize sounding boards (a structured approach to obtain active feedback from stakeholders) with key users and with representatives from the larger user groups to discuss recent challenges with the CIS and opportunities for improvements.

#### **Exercise 4.9.7 Information Systems Managers as Architects**

Health information managers can indeed be compared with architects. Health information managers design information systems that are used by many different user groups. Health information managers regularly monitor the quality of information systems to obtain feedback and to improve the information system. Health information managers understand that information systems support many different functions for many different user groups within health care facilities. Health information managers make sure that the application systems are user-friendly and support working processes in an effcient way. Health information managers understand that an information system serves the overall goal of a health care facility and ultimately serves the need of the patients.

## **Chapter 5: Quality of Health Information Systems**

#### **Exercise 5.6.1 Quality of Integration**


#### **Exercise 5.6.2 Data Collection in Evaluation Studies**

Study "Unintended Effects of a Computerized Physician Order Entry Nearly Hardstop Alert": The effectiveness of a nearly "hard-stop" alert was evaluated in a feld study. The data was collected via analysis of the prescriptions in the CPOE systems. The overall data collection method is thus a quantitative observation of available data.

Study "Clinical Decision Support for Worker Health: A Five-Site Qualitative Needs Assessment in Primary Care Setting": data were collected via interviews and qualitative observations.

#### **Exercise 5.6.3 Study Design in Evaluation Studies**

Study "Unintended Effects of a Computerized Physician Order Entry Nearly Hard-Stop Alert": This quantitative and explanatory feld study was organized as an RCT: 1981 clinicians were randomly assigned to either the intervention group or the control group. RCTs are considered the gold standard, as they provide a rigorous tool to assess cause–effect relationships between intervention and outcome.

Study "Clinical Decision Support for Worker Health: A Five-Site Qualitative Needs Assessment in Primary Care Setting": This is a qualitative, explorative feld study.

## **Chapter 6: Information Systems for Specifc Health Care and Research Settings**

#### **Exercise 6.12.1 Research Architecture**

The following entity types have to be integrated: patient, person, diagnosis, fnding, health record, medical procedure, patient record, self-gathered symptoms, material, medical device, classifcation, nomenclature.

Application components to be integrated depend on local settings and implementation but will likely include: patient administration system, MDMS, LIS, OMS, PDMS, and self-diagnosis systems (e.g., an app for collecting patient-reported outcome data) or patient portals.

A research architecture for setting up multiple registries might include a DWS for research that is fed via ETL processes from the above-mentioned application components and can be tapped for data in different use cases or research scenarios. Finally, an open platform architecture would enable reuse of patient data in various research contexts.

#### **Exercise 6.12.2 Medical Admission**

The function "medical admission" is relevant in several health care and research settings. It comprises the provision of forms for documenting medical history, documenting diagnoses, and scanning documents from referring physician and other sources of information about the medical history. It is obvious that this function needs to be supported in hospitals, nursing homes, ambulatory nursing organizations, and medical offces. Yet it is often also necessary in research settings, for example, when a person is recruited for a clinical trial and their data are entered into an EDC system. Furthermore, therapeutic offces need this function for documentation purposes, as do rehabilitation facilities and—to a limited extent—wellness or sports facilities. For personal environments, medical admission also plays a role, especially in telecare situations or when prevention measures are conducted, respectively.

# **Glossary1**


A. Winter et al., *Health Information Systems*, Health Informatics, https://doi.org/10.1007/978-3-031-12310-8

<sup>1</sup>This glossary lists all relevant terms introduced and used in this book. In the main text, these terms are written in italics when frst introduced and when defned. Application systems and functions are always written in italics in the main text. Functions are not included in the glossary.

<sup>©</sup> The Editor(s) (if applicable) and The Author(s) 2023 245


model patterns supporting the derivation of more specifc models through modifcations, limitations, or completions (generic reference models) or direct comparison of different models with the reference model concerning certain quality aspects of the modeled systems (e.g., completeness, styles of system's architecture) (non-generic reference models) (Sect. 2.13).


# **Index**

#### **A**

Acute diseases, 3 Ambulatory nursing organizations, 19, 211, 217, 227, 230, 244 Application system, 14, 16, 23–25, 35–39, 41, 43–45, 53, 65, 84, 86, 98, 99, 105, 106, 109–111, 114–118, 121, 124, 125, 128–132, 134–138, 146–149, 154, 170, 174, 179, 196, 200, 201, 204, 206, 208, 213, 215, 216, 236, 238, 239, 243 Architectural styles, 51, 52, 107, 110, 111, 113, 138 Architecture, 24, 27–29, 31, 32, 51, 82, 106–113, 129, 135, 137, 148, 159, 161, 162, 166, 167, 169, 177, 179, 184, 192, 196, 231, 234, 238,

#### **B**

Benchmarking, 166–168, 187

239, 244

#### **C**

Care, 1–5, 7–10, 16, 18, 19, 21, 22, 26, 33, 43, 52, 53, 56–59, 61, 62, 64, 66, 67, 69–74, 76, 78, 80, 85, 89, 95, 96, 99, 102, 105, 116, 124, 126, 142, 148, 159, 164, 166, 168, 174, 176–182, 188–195, 200, 206, 207, 211, 212, 214–218, 222, 224, 227, 228, 230, 231, 237–240 Case identifcation number (CIN), 58, 64

Chronic diseases, 1–4, 9, 100, 211, 213, 215, 222, 230

CIO, 22, 161–163, 175–178, 184–187, 191, 201, 229

#### **D**

Domain layer, 32–35, 38, 41, 42, 44–47, 51–53, 55–58, 60, 62–64, 67–69, 71–73, 75, 76, 78–80, 82–84, 106, 143–147, 150, 151, 155, 194–195, 219, 236–238

#### **E**


#### **F**

Function, 20–22, 24, 32–36, 38, 42, 44, 45, 55, 60–72, 74–76, 78, 82–84, 89, 90, 97, 105, 117, 133, 143, 145, 147, 151, 160, 163, 181, 188, 197, 219, 226, 234, 236–240, 244

#### **H**

Health care settings, 2, 13, 16–33, 35, 42–44, 51–53, 59, 60, 69, 85, 103, 106, 107, 111, 132, 140, 153, 154, 211–213, 222–225, 227–228, 230, 234

© The Editor(s) (if applicable) and The Author(s) 2023 A. Winter et al., *Health Information Systems*, Health Informatics, https://doi.org/10.1007/978-3-031-12310-8

Hospital, 2, 11, 13, 16–18, 20–22, 24, 29, 31, 35, 42, 45–47, 58, 64, 66, 72, 76, 78, 80, 84, 85, 90, 92, 99, 100, 103, 105–107, 109, 111, 118, 119, 129, 130, 132, 139, 140, 143–146, 150, 151, 159, 163, 181–187, 192, 195, 196, 202, 213–216, 219, 224, 226–231, 233, 235–237, 241

#### **I**


#### **L**

Life situations, 2–4, 11, 12, 16, 18, 51, 52, 61, 211, 230–231, 235 Logical tool layer, 32, 35–39, 41, 43–47, 51, 52, 84, 86–90, 92–98, 100–102, 104–108, 110, 111, 113–115, 117–121, 123–125, 127, 128, 130, 132, 133, 135–138, 140–142, 146, 148, 149, 151, 179, 196, 233, 237–239

#### **M**

Management perspective, 2, 51, 211, 212, 214–217, 221–222, 226, 227, 229 Medical device regulation (MDR), 59 Medical offces, 3, 5, 10, 16, 18–20, 65, 85, 86, 90, 145–148, 150, 211, 215–217, 226–228, 230, 244 Medical research facility, 212, 218–221

#### **N**

Nursing homes, 4, 19, 29, 66, 105, 195, 211, 214, 230, 244

#### **O**

Operational management, 82, 153–158, 166, 170–174, 176–178, 185, 190, 191, 193, 194, 211

#### **P**

Patient identifcation number (PIN), 56, 57 Personal environments, 2, 19, 212, 226–227, 230, 244 Physical data processing systems, 23–25, 27–29, 32, 36, 39–41, 44, 45, 48, 51, 85, 91, 120, 125, 138–142, 150, 155, 162, 164, 183, 192–194, 197, 221, 236, 237 Physical tool layer, 32, 39–41, 44–46, 51, 52, 107, 114, 120, 122, 125, 138–143, 149–151, 179, 180, 197, 215, 217 Prevention, 2–4, 9, 18, 25, 57, 58, 61–63, 101, 207, 225, 227, 230, 244 Project portfolio, 156, 159, 160, 162–165, 167, 170, 175, 177, 183, 186, 191, 192, 240

#### **Q**

Quality characteristics, 132, 133, 189, 193, 196, 198, 199 Quality of architectures, 194 Quality of integration, 198–199, 204, 208, 242 Quality of IT governance, 190 Quality of operational management, 193 Quality of strategic management, 167, 191–192 Quality of tactical management, 167, 192–193

#### **R**

Rehabilitation, 3, 4, 11, 18–20, 25, 29, 32, 58, 66, 72, 85, 99, 100, 212, 222–227, 230, 244 Research, 1, 4, 7, 19, 53, 54, 59, 71, 97, 118, 128, 130, 143, 159, 181, 182, 191, 213, 218–221, 231, 233, 234, 237, 244 Researchers, 7, 11

#### **S**

Service orchestration, 230

Stakeholders, 2, 4–10, 12, 20, 22, 52, 153, 157, 161, 162, 166, 175, 176,

178–180, 189–192, 199, 211, 214, 235, 242 Strategic alignment, 159–160, 162, 168, 186, 240 Strategic management, 82, 153–156, 158–161, 166, 168, 169, 177, 178, 180, 191, 193

#### **T**

Tactical management, 82, 131, 155, 156, 166,

169–171, 173, 177, 192, 193, 199 Technological perspective, 51, 54–56, 58–63, 65, 67–69, 71–74, 76, 78, 79, 81–85, 87, 88, 90–92, 94, 96–99, 101, 102, 104–107, 109, 111,


#### **W**

Wellness, 3, 9, 125, 222, 225–227, 230, 244